Lang Hames [Tue, 29 Jul 2014 23:43:13 +0000 (23:43 +0000)]
[MCJIT] Add options to llvm-rtdyld to describe a phony target address space for
use in -verify mode.
This patch adds three hidden command line options to llvm-rtdyld:
-target-addr-start <start-addr> : Specify the start of the virtual address
space on the phony target.
-target-addr-end <end-addr> : Specify the end of the virtual address space
on the phony target.
-target-section-sep <sep> : Specify the separation (in bytes) between the
end of one section and the start of the next.
These options automatically default to sane values for the target platform. In
particular, they allow narrow (e.g. 32-bit, 16-bit) targets to be tested from
wider (e.g. 64-bit, 32-bit) hosts without overflowing pointers.
The section separation option defaults to zero, but can be set to a large number
(e.g. 1 << 32) to force large separations between sections in order to
stress-test large-code-model code.
Revert "UseListOrder: Order GlobalValue uses after initializers"
This reverts commits r214242 and r214243 while I investigate buildbot
failures [1][2][3]. I can't reproduce these failures locally, so if
anyone can see what I've done wrong, I'd appreciate a note.
UseListOrder: Additional test coverage for r214242
r214242 was subtle enough it really deserves a targeted test with
comments. This adds some global variables that trigger the relevant
code path. Sorry this wasn't committed with the fix.
UseListOrder: Order GlobalValue uses after initializers
To avoid unnecessary forward references, the reader doesn't process
initializers of `GlobalValue`s until after the constant pool has been
processed, and then in reverse order. Model this when predicting
use-list order. This gets two more Bitcode tests passing with
`llvm-uselistorder`.
This moves some tests around to make it clearer what's being tested,
and adds very rudimentary comment syntax to the text input format to
make specifying this kind of test a little bit simpler.
Lang Hames [Tue, 29 Jul 2014 21:48:22 +0000 (21:48 +0000)]
[MCJIT] XFAIL some RuntimeDyld tests on MIPS - RuntimeDyldChecker isn't properly
endian-aware yet, and this is causing failures when cross-linking on MIPS.
C:/lld-x86_64_win7/lld-x86_64-win7/llvm.src/include\llvm/IR/UseListOrder.h(92): error C2248: 'llvm::UseListShuffleVector::operator =' : cannot access private member declared in class 'llvm::UseListShuffleVector' (C:\lld-x86_64_win7\lld-x86_64-win7\llvm.src\lib\Bitcode\Writer\ValueEnumerator.cpp) [C:\lld-x86_64_win7\lld-x86_64-win7\llvm.obj\lib\Bitcode\Writer\LLVMBitWriter.vcxproj]
C:/lld-x86_64_win7/lld-x86_64-win7/llvm.src/include\llvm/IR/UseListOrder.h(56) : see declaration of 'llvm::UseListShuffleVector::operator ='
C:/lld-x86_64_win7/lld-x86_64-win7/llvm.src/include\llvm/IR/UseListOrder.h(32) : see declaration of 'llvm::UseListShuffleVector'
This diagnostic occurred in the compiler generated function 'llvm::UseListOrder &llvm::UseListOrder::operator =(const llvm::UseListOrder &)'
Remove the copy constructor added in r214178 to appease MSVC17 since it
shouldn't be called at all. My guess is that explicitly deleting it
will make the compiler happy. To round out the operations I've also
deleted copy assignment and added move assignment. Otherwise no
functionality change.
Lang Hames [Tue, 29 Jul 2014 20:40:37 +0000 (20:40 +0000)]
[MCJIT] Make the RuntimeDyldChecker stub_addr builtin use file names rather than
full paths for its first argument.
This allows us to remove the annoying sed lines in the test cases, and write
direct references to file names in stub_addr calls (rather than <filename>
placeholders).
Rafael Espindola [Tue, 29 Jul 2014 20:22:46 +0000 (20:22 +0000)]
Move the bitcode error enum to the include directory.
This will let users in other libraries know which error occurred. In particular,
it will be possible to check if the parsing failed or if the file is not
bitcode.
[Debug Info] remove DITrivialType and use null to represent unspecified param.
Per feedback on r214111, we are going to use null to represent unspecified
parameter. If the type array is {null}, it means a function that returns void;
If the type array is {null, null}, it means a variadic function that returns
void. In summary if we have more than one element in the type array and the last
element is null, it is a variadic function.
Tim Northover [Tue, 29 Jul 2014 09:56:38 +0000 (09:56 +0000)]
ARM: fix @llvm.convert.from.fp16 on softfloat targets.
We need to make sure we use the softened version of all appropriate operands in
the libcall, or things go horribly wrong. This may entail actually executing a
1-stage softening.
Fix the sort of expected order in the reader to correctly return `false`
when comparing a `Use` against itself.
This was caught by test/Bitcode/binaryIntInstructions.3.2.ll, so I'm
adding a `RUN` line using `llvm-uselistorder` for every test in
`test/Bitcode` that passes.
A few tests still fail, so I'll investigate those next.
Hans Wennborg [Mon, 28 Jul 2014 22:10:52 +0000 (22:10 +0000)]
Update LLVM version: 3.5 => 3.6
We branched 3.5, it's now time to work on 3.6.
This is Sylvestre's patch from [1] plus regenerated configure
file by me, and minus the release notes reset, which Sean
pointed out [2] should happen later.
Predict and serialize use-list order in bitcode. This makes the option
`-preserve-bc-use-list-order` work *most* of the time, but this is still
experimental.
- Builds a full value-table up front in the writer, sets up a list of
use-list orders to write out, and discards the table. This is a
simpler first step than determining the order from the various
overlapping IDs of values on-the-fly.
- The shuffles stored in the use-list order list have an unnecessarily
large memory footprint.
- `blockaddress` expressions cause functions to be materialized
out-of-order. For now I've ignored this problem, so use-list orders
will be wrong for constants used by functions that have block
addresses taken. There are a couple of ways to fix this, but I
don't have a concrete plan yet.
- When materializing functions lazily, the use-lists for constants
will not be correct. This use case is out of scope: what should the
use-list order be, if it's incomplete?
[Debug Info] rename getTypeArray to getElements, setTypeArray to setArrays.
This is the second of a series of patches to handle type uniqueing of the
type array for a subroutine type.
For vector and array types, getElements returns the array of subranges, so it
is a better name than getTypeArray. Even for class, struct and enum types,
getElements returns the members, which can be subprograms.
setArrays can set up to two arrays, the second is the templates.
[SDAG] Add DEBUG logging to the legalizer, fixing a "bug" found by
inspection in the proccess, and shuffle the logging in the DAG combiner
around a bit.
With this it is much easier to follow what the legalizer is doing. It
should even accurately present most of the strange legalization
operations where a single node is replaced by multiple nodes, etc. There
is still some information lost (we log SDNodes not SDValues so we don't
log which result is used for which thing), but I think this is much
closer to a usable system. Notably, this will make it *much* more
apparant when legalization is actually happening inside the combiner, or
when there is a cycle caused by interactions of the legalizer and the
combiner.
The "bug" I fixed here I'm not sure is remotely possible to trigger. We
were only adding one of the nodes in a replacement to the updated set
rather than all of the nodes in the replacement. Realistically, the
worst result of this are nodes not getting back onto the worklist in the
DAG combiner. I doubt it is possible to trigger this today, and
I certainly don't have any ideas about how, but this at least brings the
code into alignment with the principled operation of the routine.
Dan Liew [Mon, 28 Jul 2014 13:36:50 +0000 (13:36 +0000)]
Emit a warning if llvm_map_components_to_libraries() is used noting that its
use is deprecated in favour of llvm_map_components_to_libnames()
Although message(DEPRECATION "msg") would probably be a better fit this
does nothing if CMAKE_ERROR_DEPRECATED and CMAKE_WARNING_DEPRECATED are
both off, which is the default.
[PowerPC] Support ELFv1/ELFv2 ABI selection via features
While LLVM now supports both ELFv1 and ELFv2 ABIs, their use is currently
hard-coded via the target triple: powerpc64-linux is always ELFv1, while
powerpc64le-linux is always ELFv2.
These are of course the most common scenarios, but in principle it is
possible to support the ELFv2 ABI on big-endian or the ELFv1 ABI on
little-endian systems (and GCC does support that), and there are some
special use cases for that (e.g. certain Linux kernel versions could
only be built using ELFv1 on LE).
This patch implements the LLVM side of supporting this. As precedent
on other platforms suggests, ABI options are passed to the back-end as
features. Thus, this patch implements two features "elfv1" and "elfv2"
that select the desired ABI if present. (If not, the LLVM uses the
same default rules as now.)
Rafael Espindola [Sun, 27 Jul 2014 23:11:06 +0000 (23:11 +0000)]
Start adding some tests for the gold plugin.
These are only used when the 'ld' in the path is gold and the plugin has
been built, but it is already a start to make sure we don't regress features
that cannot be tested with llvm-lto.
ARM: correct handling of features in arch_extension
The subtarget information is the ultimate source of truth for the feature set
that is enabled at this point. We would previously not propagate the feature
information to the subtarget. While this worked for the most part (features
would be enabled/disabled as requested), if another operation that changed the
feature bits was encountered (such as a mode switch via a .arm or .thumb
directive), we would end up resetting the behaviour of the architectural
extensions.
Handling this properly requires a slightly more complicated handling. We need
to check if the feature is now being toggled. If so, only then do we toggle the
features. In return, we no longer have to calculate the feature bits ourselves.
The test changes are mostly to the diagnosis, which is now more uniform (a nice
side effect!). Add an additional test to ensure that we handle this case
properly.
Thanks to Nico Weber for alerting me to this issue!
Matt Arsenault [Sun, 27 Jul 2014 17:46:40 +0000 (17:46 +0000)]
Add alignment value to allowsUnalignedMemoryAccess
Rename to allowsMisalignedMemoryAccess.
On R600, 8 and 16 byte accesses are mostly OK with 4-byte alignment,
and don't need to be split into multiple accesses. Vector loads with
an alignment of the element type are not uncommon in OpenCL code.
projects / llvm / log