fields were only ever set in the constructor. The create method retains
its consistent interface so that these bits can be re-threaded through
the emitter if they're ever needed.
This was found by the -Wunused-private-field Clang warning.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175482 91177308-0d34-0410-b5e6-96231b3b80d8
If the memcpy has an odd length with an alignment of 2, this would incorrectly
assert on the last 1 byte copy.
rdar://13202135
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175459 91177308-0d34-0410-b5e6-96231b3b80d8
Also, GetElementPtrInst::getType() method returns SequentialType now, instead of
PointerType. There wasn't any issue yet, so no testcase attached.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175452 91177308-0d34-0410-b5e6-96231b3b80d8
NOTE: This is a candidate for the Mesa stable branch.
Reviewed-by: Tom Stellard <thomas.stellard at amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175445 91177308-0d34-0410-b5e6-96231b3b80d8
We already use features from 2.8.6, this just gives a slightly more friendly
message when the dependency isn't met.
Patch from Keith Walker.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175434 91177308-0d34-0410-b5e6-96231b3b80d8
Profiling tests *do* need a JIT. They'll pass if a cross-compiler targetting
AArch64 by default has been built, but fail if a native AArch64 compiler has
been build. Therefore XFAIL is inappropriate and we mark them unsupported.
ExecutionEngine tests are JIT by definition, they should also be unsupported.
Transforms/LICM only uses the interpreter to check the output is still sane
after optimisation. It can be switched to use an interpreter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175433 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we seemed to be assuming that all functions were definitions and all
methods were declarations. This may be consistent with how Clang uses DIBuilder
but doesn't have to be true of all clients (such as DragonEgg).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175423 91177308-0d34-0410-b5e6-96231b3b80d8
at this time, llvm is generating a different but equivalent pattern
that would lead to this instruction. I am trying to think of a way
to get it to generate this. If I can't, I may just remove the pseudo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175419 91177308-0d34-0410-b5e6-96231b3b80d8
This expansion will be moved to expandISelPseudos as soon as I can figure
out how to do that. There are other instructions which use this
ExpandFEXT_T8I816_ins and as soon as I have finished expanding them all,
I will delete the macro asm string text so it has no way to be used
in the future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175413 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes PR15289. This bug was introduced (recently) in r175215; collecting
all std::vector references for candidate pairs to delete at once is invalid
because subsequent lookups in the owning DenseMap could invalidate the
references.
bugpoint was able to reduce a useful test case. Unfortunately, because whether
or not this asserts depends on memory layout, this test case will sometimes
appear to produce valid output. Nevertheless, running under valgrind will
reveal the error.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175397 91177308-0d34-0410-b5e6-96231b3b80d8
GCC warns about the attribute being ignored if it occurs after void*.
There seems to be some kind of incompatibility between clang and gcc here, but
I can't fathom who's right.
void* LLVM_LIBRARY_VISIBILITY foo(); // clang: hidden, gcc: default
LLVM_LIBRARY_VISIBILITY void *bar(); // clang: hidden, gcc: hidden
void LLVM_LIBRARY_VISIBILITY qux(); // clang: hidden, gcc: hidden
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175394 91177308-0d34-0410-b5e6-96231b3b80d8
