This commit moves getSLEB128Size() and getULEB128Size() from
MCAsmInfo to LEB128.h and removes some copy-and-paste code.
Besides, this commit also adds some unit tests for the LEB128
functions.
llvm-svn: 201937
This reverts commit r201921.
This should bring the polly bots back. I will try to build it locally to
understand how cmake was setting the rpath of LLVMPolly.so.
llvm-svn: 201934
The operator+() and operator-() do not change the member
variables of SuccIterator. This CL will qualify the *this*
pointer with const.
llvm-svn: 201933
For targeting pecoff, ".def foo" appears before ".short 32".
.def foo;
...
.LCPI0_0:
.short 32
foo:
CHECK-LABEL seeks not from ".short 32" but from the top of the input.
llvm-svn: 201931
This works by asking cmake to use the "install rpath", but setting that rpath
to be relative.
Thanks a lot to Brad King for the help with CMake!
llvm-svn: 201921
The LLVM diagnostic are now wired-up in clang (since r200931),
thus the user experience will not be impacted by this change
anymore.
Related to <rdar://problem/15886697>
llvm-svn: 201915
CodeGenPrepare uses extensively TargetLowering which is part of libLLVMCodeGen.
This is a layer violation which would introduce eventually a dependence on
CodeGen in ScalarOpts.
Move CodeGenPrepare into libLLVMCodeGen to avoid that.
Follow-up of <rdar://problem/15519855>
llvm-svn: 201912
shifted mask rather than masking and shifting separately.
The patch adds this transformation to the DAGCombiner:
(shl (and (setcc:i8v16 ...) N01C) N1C) -> (and (setcc:i8v16 ...) N01C<<N1C)
<rdar://problem/16054492>
Patch by Adam Nemet <anemet@apple.com>
llvm-svn: 201906
The lowering of the frame index for stackmaps and patchpoints requires some
target-specific magic and should therefore be handled in the target-specific
eliminateFrameIndex method.
This is related to <rdar://problem/16106219>
llvm-svn: 201904
This interface allows IRObjectFile to be implemented without having dummy
methods for all section and segment related methods.
Both llvm-ar and llvm-nm are changed to use it. Unfortunately the mangler is
still not plugged in since it requires some refactoring to make a Module hold
a DataLayout.
llvm-svn: 201881
We were just emitting a label for this section for no real reason - this
caused us to emit the section even though we never put anything in it.
Not bothering with a test (though not adamantly anti-test) because it
seems somewhat arbitrary to test for the absence of this section anymore
than the absence of any other section.
llvm-svn: 201876
in the dependence test, we used to discard some information that the
delinearization provides: the size of the innermost dimension of an array,
i.e., the size of scalars stored in the array, and the remainder of the
delinearization that provides the offset from which the array reads start,
i.e., the base address of the array.
To avoid losing this data in the rest of the data dependence analysis, the fix
is to multiply the access function in the last delinearized dimension by its
size, effectively making the size of the last dimension to always be in bytes,
and then add the remainder of delinearization to the last subscript,
effectively making the last subscript start at the base address of the array.
llvm-svn: 201867
Because the delinearization is not a global analysis pass, it will compute the
delinearization independently of knowledge about the way the delinearization
happened for other data accesses to the same array: the dependence analysis will
only trigger the delinearization on a tuple of access functions, and thus
delinearization may compute different subscripts sizes for a same array. When
that happens the safest is to discard the delinearized information.
llvm-svn: 201866
llvm_add_library(foo SHARED STATIC
DEPENDS <dependent targets...>
LINK_LIBS <required libraries...>
)
It generates both foo (foo.so) and foo_static(foo.a) and both of them depend on DEPENDS and LINK_LIBS.
Then, also obj.foo is generated. obj.foo depends on DEPENDS, but doesn't depend on LINK_LIBS.
llvm-svn: 201854
The module still needs to collect the list of all available libraries
in order to satisfy the 'all' component. Provide this in the package
configuration file, 'LLVMConfig.cmake', as a LLVM_AVAILABLE_LIBS
variable. (A variable is scoped better than a global property.)
Since this won't be set for our own build, fall back to looking up the
LLVM_LIBS property to get the value when it is not set.
Contributed by Brad King.
llvm-svn: 201853
LLVM library names are now available as logical CMake targets both
to our own build and to application CMake code. Replace use of
'list(FIND)' with a simple 'if(TARGET)' to determine whether a
library is available.
Contributed by Brad King.
llvm-svn: 201852
This replaces the old NoIntegratedAssembler with at TargetOption. This is
more flexible and will be used to forward clang's -no-integrated-as option.
llvm-svn: 201836
I am really sorry for the noise, but the current state where some parts of the
code use TD (from the old name: TargetData) and other parts use DL makes it
hard to write a patch that changes where those variables come from and how
they are passed along.
llvm-svn: 201827
should not be marked nounwind.
Marking them nounwind caused crashes in the WebKit FTL JIT, because if we enable
sufficient optimizations, LLVM starts eliding compact_unwind sections (or any unwind
data for that matter), making deoptimization via stackmaps impossible.
This changes the stackmap intrinsic to be may-throw, adds a test for exactly the
sympton that WebKit saw, and fixes TableGen to handle un-attributed intrinsics.
Thanks to atrick and philipreames for reviewing this.
llvm-svn: 201826
The SuppressWarnings flag, unfortunately, isn't very useful for custom tools
that want to use the LLVM module linker. So I'm changing it to a parameter of
the Linker, and the flag itself moves to the llvm-link tool.
For the time being as SuppressWarnings is pretty much the only "option" it
seems reasonable to propagate it to Linker objects. If we end up with more
options in the future, some sort of "struct collecting options" may be a
better idea.
llvm-svn: 201819
The va_start macro for AArch64 must set va_list.__stack to the address
following the last named argument on the stack, rounded up to an alignment
of 8 bytes.
llvm-svn: 201797
