The exit-on-error flag on the many_args1.ll test is needed to avoid an
unreachable in BPFTargetLowering::LowerCall. We can also avoid it by ignoring
any superfluous arguments to the call (i.e. any arguments after the first 5).
Fixes PR27766
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270419 91177308-0d34-0410-b5e6-96231b3b80d8
This code should have been with the previous check-in (r270417) and prevents the DelaySlotFiller pass being utilized in functions where the erratum fix has been applied as this will break the run-time code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270418 91177308-0d34-0410-b5e6-96231b3b80d8
Due to an erratum in some versions of LEON, we must insert a NOP after any LD or LDF instruction to ensure the processor has time to load the value correctly before using it. This pass will implement that erratum fix.
The code will have no effect for other Sparc, but non-LEON processors.
Differential Review: http://reviews.llvm.org/D20353
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270417 91177308-0d34-0410-b5e6-96231b3b80d8
If TheModule is declared before LLVMContext then it will be destructed after it,
crashing when it tries to deregister itself from the destructed context.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270381 91177308-0d34-0410-b5e6-96231b3b80d8
This isn't the complete fix, but it handles the trivial examples of duplicate vzero* ops in PR27823:
https://llvm.org/bugs/show_bug.cgi?id=27823
...and amusingly, the bogus cases already exist as regression tests, so let's take this baby step.
We'll need to do more in the general case where there's legitimate AVX usage in the function + there's
already a vzero in the code.
Differential Revision: http://reviews.llvm.org/D20477
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270378 91177308-0d34-0410-b5e6-96231b3b80d8
We could try harder to handle non-splat vector constants too,
but that seems much rarer to me.
Note that the div test isn't resolved because there's a check
for isIntegerTy() guarding that transform.
Differential Revision: http://reviews.llvm.org/D20497
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270369 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a bug introduced in:
r262115 - CodeGen: Take MachineInstr& in SlotIndexes and LiveIntervals, NFC
The iterator End here might == MBB->end(), and so we can't unconditionally
dereference it. This often goes unnoticed (I don't have a test case that always
crashes, and ASAN does not catch it either) because the function call arguments are
turned right back into iterators. MachineInstrBundleIterator's constructor,
however, does have an assert which might randomly fire.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270323 91177308-0d34-0410-b5e6-96231b3b80d8
Main problem here was that SHF_COMPRESSED has the same value with
XCORE_SHF_CP_SECTION, which was included as standart (common) flag.
As far I understand xCore is a family of controllers and it that
means it's constant should be processed separately,
only if e_machine == EM_XCORE, otherwise llvm-readobj would output
different constants twice for compressed section:
Flags [
..
SHF_COMPRESSED (0x800)
..
XCORE_SHF_CP_SECTION (0x800)
..
]
what probably does not make sence if you're not working with xcore file.
Differential revision: http://reviews.llvm.org/D20273
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270320 91177308-0d34-0410-b5e6-96231b3b80d8
A cleanuppad is not cheap, they turn into many instructions and result
in additional spills and fills. It is not worth keeping a cleanuppad
around if all it does is hold a lifetime.end instruction.
N.B. We first try to merge the cleanuppad with another cleanuppad to
avoid dropping the lifetime and debug info markers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270314 91177308-0d34-0410-b5e6-96231b3b80d8
Allocating larger register classes first should give better allocation
results (and more importantly for myself, make the lit tests more stable
with respect to scheduler changes).
Patch by Matthias Braun
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270312 91177308-0d34-0410-b5e6-96231b3b80d8
The InductiveRangeCheck struct is only five words long; so passing these
around value is fine. The allocator makes the code look more complex
than it is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270309 91177308-0d34-0410-b5e6-96231b3b80d8
These are kind of a mess and hard to follow, particularly
for loads and stores. Fix various redundant, unnecessary
and dead settings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270307 91177308-0d34-0410-b5e6-96231b3b80d8
I had used `std::remove_if` under the assumption that it moves the
predicate matching elements to the end, but actaully the elements
remaining towards the end (after the iterator returned by
`std::remove_if`) are indeterminate. Fix the bug (and make the code
more straightforward) by using a temporary SmallVector, and add a test
case demonstrating the issue.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270306 91177308-0d34-0410-b5e6-96231b3b80d8
