We supported creating mergeable constant pool entries for smaller
constants but not for 32-byte AVX constants.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261584 91177308-0d34-0410-b5e6-96231b3b80d8
This was causing assertions later from using the wrong pointer
size with LDS operations. getOptimalMemOpType should also have
address space arguments later.
This avoids assertions in existing tests exposed by
a future commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261580 91177308-0d34-0410-b5e6-96231b3b80d8
Previously the stack pointer was only written back to memory in the
prolog. But this is wrong for dynamic allocas, for which
target-independent codegen handles SP updates after the prolog (and
possibly even in another BB). Instead update the SP global in
ADJCALLSTACKDOWN which is generated after the SP update sequence.
This will have further refinements when we add red zone support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261579 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Since this is an IR pass it's nice to be able to write tests without
llc. This is the counterpart of the llc test under
CodeGen/PowerPC/loop-data-prefetch.ll.
Reviewers: hfinkel
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17464
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261578 91177308-0d34-0410-b5e6-96231b3b80d8
This is a little embarrassing.
When I reverted r261504 (getIterator() => getInstrIterator()) in
r261567, I did a `git grep` to see if there were new calls to
`getInstrIterator()` that I needed to migrate. There were 10-20 hits,
and I blindly did a `sed ...` before calling `ninja check`.
However, these were `MachineInstrBundleIterator::getInstrIterator()`,
which predated r261567. Perhaps coincidentally, these had an identical
name and return type.
This commit undoes my careless sed and restores
`MachineBasicBlock::iterator::getInstrIterator()`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261577 91177308-0d34-0410-b5e6-96231b3b80d8
The issue was that we only required LCSSA rebuilding if the immediate
parent-loop had values used outside of it. The fix is to enaable the
same logic for all outer loops, not only immediate parent.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261575 91177308-0d34-0410-b5e6-96231b3b80d8
I don't think this test was intending to test unaligned load/store.
Change it to use the natural alignment to avoid regressing.
Also adds missing SI checks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261571 91177308-0d34-0410-b5e6-96231b3b80d8
This avoids some test regressions in a future commit
when unaligned operations are expanded when they
have custom lowering.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261570 91177308-0d34-0410-b5e6-96231b3b80d8
This flag was part of a migration to a new means of handling vectors-of-points which was described in the llvm-dev thread "FYI: Relocating vector of pointers". The old code path has been off by default for a while without complaints, so time to cleanup.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261569 91177308-0d34-0410-b5e6-96231b3b80d8
DMB instructions can be expensive, so it's best to avoid them if possible. In
atomicrmw operations there will always be an attempted store so a release
barrier is always needed, but in the cmpxchg case we can delay the DMB until we
know we'll definitely try to perform a store (and so need release semantics).
In the strong cmpxchg case this isn't quite free: we must duplicate the LDREX
instructions to skip the barrier on subsequent iterations. The basic outline
becomes:
ldrex rOld, [rAddr]
cmp rOld, rDesired
bne Ldone
dmb
Lloop:
strex rRes, rNew, [rAddr]
cbz rRes Ldone
ldrex rOld, [rAddr]
cmp rOld, rDesired
beq Lloop
Ldone:
So we'll skip this version for strong operations in "minsize" functions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261568 91177308-0d34-0410-b5e6-96231b3b80d8
This change reverts "246133 [RewriteStatepointsForGC] Reduce the number of new instructions for base pointers" and a follow on bugfix 12575.
As pointed out in pr25846, this code suffers from a memory corruption bug. Since I'm (empirically) not going to get back to this any time soon, simply reverting the problematic change is the right answer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261565 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM converts adds into ors when it can prove that the operands don't share
any non-zero bits. Teach address folding to recognize or instructions with
constant operands with this property that can be folded into addresses as
if they were adds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261562 91177308-0d34-0410-b5e6-96231b3b80d8
This is what was meant to be in the initial commit to fix this bug. The
parens were missing. This commit also adds a test case for the bug and
has undergone full testing on PPC and X86.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261546 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Previously we had a notion of convergent functions but not of convergent
calls. This is insufficient to correctly analyze calls where the target
is unknown, e.g. indirect calls.
Now a call is convergent if it targets a known-convergent function, or
if it's explicitly marked as convergent. As usual, we can remove
convergent where we can prove that no convergent operations are
performed in the call.
Reviewers: chandlerc, jingyue
Subscribers: hfinkel, jhen, tra, llvm-commits
Differential Revision: http://reviews.llvm.org/D17317
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261544 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Convergent instrs shouldn't be made control-dependent on other values,
but this is basically the whole point of tail duplication. So just bail
if we see a convergent instruction.
Reviewers: iteratee
Subscribers: jholewinski, jhen, hfinkel, tra, jingyue, llvm-commits
Differential Revision: http://reviews.llvm.org/D17320
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261540 91177308-0d34-0410-b5e6-96231b3b80d8
Rename makeNoWrapRegion to a more obvious makeGuaranteedNoWrapRegion,
and add a comment about the counter-intuitive aspects of the function.
This is to help prevent cases like PR26628.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261532 91177308-0d34-0410-b5e6-96231b3b80d8
I mistook BitVector::empty() to mean BitVector::count() == 0 and it does
not. Corrected the issue with the fix for PR26500.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261525 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r261510, effectively reapplying r261509. The
original commit missed a caller in AArch64ConditionalCompares.
Original commit message:
Pass non-null arguments by reference in MachineTraceMetrics::Trace,
simplifying future work to remove implicit iterator => pointer
conversions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261511 91177308-0d34-0410-b5e6-96231b3b80d8
Pass non-null arguments by reference in MachineTraceMetrics::Trace,
simplifying future work to remove implicit iterator => pointer
conversions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261509 91177308-0d34-0410-b5e6-96231b3b80d8
Delete MachineInstr::getIterator(), since the term "iterator" is
overloaded when talking about MachineInstr.
- Downcast to ilist_node in iplist::getNextNode() and getPrevNode() so
that ilist_node::getIterator() is still available.
- Add it back as MachineInstr::getInstrIterator(). This matches the
naming in MachineBasicBlock.
- Add MachineInstr::getBundleIterator(). This is explicitly called
"bundle" (not matching MachineBasicBlock) to disintinguish it clearly
from ilist_node::getIterator().
- Update all calls. Some of these I switched to `auto` to remove
boiler-plate, since the new name is clear about the type.
There was one call I updated that looked fishy, but it wasn't clear what
the right answer was. This was in X86FrameLowering::inlineStackProbe(),
added in r252578 in lib/Target/X86/X86FrameLowering.cpp. I opted to
leave the behaviour unchanged, but I'll reply to the original commit on
the list in a moment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261504 91177308-0d34-0410-b5e6-96231b3b80d8
The resolver uses the fxsave/fxrstor instructions, which require 16-byte
alignment, to save SSE state to the stack. Since 16-byte alignment can't be
assumed on all OSes (and all i386 OSes share this function) - add code to
automatically bump the alignment to 16-bytes on entry to the function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261503 91177308-0d34-0410-b5e6-96231b3b80d8
Split MachineBasicBlock::bundle_iterator into a separate file, and
rename the class to MachineBundleIterator.
This is a precursor to adding a `MachineInstr::getBundleIterator()`
accessor, which will eventually let us delete the final call to
getNodePtrUnchecked(), and then remove the UB from ilist_iterator.
As a drive-by, I removed an unnecessary second template parameter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261502 91177308-0d34-0410-b5e6-96231b3b80d8
I completely missed these non-class operators when I removed the
implicit conversions in r252380. Remove them now. r261498 should have
already removed all uses.
Note (repeated from r252380): if you have out-of-tree code, it should be
fairly easy to revert this patch downstream while you update your
out-of-tree call sites. Note that these conversions are occasionally
latent bugs (that may happen to "work" now, but only because of getting
lucky with UB; follow-ups will change your luck). When they are valid,
I suggest using `->getIterator()` to go from pointer to iterator, and
`&*` to go from iterator to pointer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261499 91177308-0d34-0410-b5e6-96231b3b80d8
I missed == and != when I removed implicit conversions between iterators
and pointers in r252380 since they were defined outside ilist_iterator.
Since they depend on getNodePtrUnchecked(), they indirectly rely on UB.
This commit removes all uses of these operators. (I'll delete the
operators themselves in a separate commit so that it can be easily
reverted if necessary.)
There should be NFC here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261498 91177308-0d34-0410-b5e6-96231b3b80d8
