| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 261573
|
|
|
|
|
|
|
|
| |
This avoids some test regressions in a future commit
when unaligned operations are expanded when they
have custom lowering.
llvm-svn: 261570
|
|
|
|
|
|
| |
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.
llvm-svn: 261569
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 261568
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r261504, since it's not obvious the new name is
better:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160222/334298.html
I'll recommit if we get consensus that it's the right direction.
llvm-svn: 261567
|
|
|
|
| |
llvm-svn: 261566
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 261565
|
|
|
|
|
|
| |
clang r261557 lowers va_arg in clang.
llvm-svn: 261564
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 261562
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by: Artem Tamazov
Summary:
Note: Support for 64-bit inline literals TBD
Added: Support of abs/neg modifiers for literals (incomplete; parsing TBD).
Added: Some TODO comments.
Reworked/clarity: rename isInlineImm() to isInlinableImm()
Reworked/robustness: disallow BitsToFloat() with undefined value in isInlinableImm()
Reworked/reuse: isSSrc32/64(), isVSrc32/64()
Tests added.
Reviewers: tstellarAMD, arsenm
Subscribers: vpykhtin, nhaustov, SamWot, arsenm
Projects: #llvm-amdgpu-spb
Differential Revision: http://reviews.llvm.org/D17204
llvm-svn: 261559
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by: Artem Tamazov
Summary: Tests added.
Reviewers: tstellarAMD, arsenm
Subscribers: vpykhtin, SamWot, #llvm-amdgpu-spb
Projects: #llvm-amdgpu-spb
Differential Revision: http://reviews.llvm.org/D17271
llvm-svn: 261558
|
|
|
|
|
|
|
| |
This reverts r261544, which was causing a test failure in
Transforms/FunctionAttrs/readattrs.ll.
llvm-svn: 261549
|
|
|
|
|
|
|
|
| |
MIs in ifcnv."
This reverts r261543. Accidental commit (not LGTM'ed).
llvm-svn: 261547
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 261546
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 261544
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Also add a comment briefly explaining what ifcnv is.
No functional changes.
Reviewers: resistor
Subscribers: echristo, tra, llvm-commits
Differential Revision: http://reviews.llvm.org/D17430
llvm-svn: 261543
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17466
llvm-svn: 261541
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 261540
|
|
|
|
| |
llvm-svn: 261538
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 261532
|
|
|
|
|
|
|
|
| |
Author: obucina
Reviewers: dsanders
Differential Revision: http://reviews.llvm.org/D15745
llvm-svn: 261529
|
|
|
|
| |
llvm-svn: 261527
|
|
|
|
|
|
|
| |
I mistook BitVector::empty() to mean BitVector::count() == 0 and it does
not. Corrected the issue with the fix for PR26500.
llvm-svn: 261525
|
|
|
|
| |
llvm-svn: 261524
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17498
llvm-svn: 261521
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17500
llvm-svn: 261520
|
|
|
|
|
|
|
|
| |
By Ayal Zaks.
Differential Revision http://reviews.llvm.org/D17258
llvm-svn: 261517
|
|
|
|
| |
llvm-svn: 261515
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 261511
|
|
|
|
|
|
|
| |
This reverts commit r261509. I'm not sure how this compiled locally,
but something was out of whack.
llvm-svn: 261510
|
|
|
|
|
|
|
|
| |
Pass non-null arguments by reference in MachineTraceMetrics::Trace,
simplifying future work to remove implicit iterator => pointer
conversions.
llvm-svn: 261509
|
|
|
|
| |
llvm-svn: 261508
|
|
|
|
|
|
|
|
| |
Resolve FIXME from r261504. Apparently bundled instructions are illegal
here:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160215/334146.html
llvm-svn: 261507
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 261504
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 261503
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 261498
|
|
|
|
|
|
|
|
|
|
| |
Stop relying on `getNodePtrUnchecked()` being useful on invalid
iterators. This function is documented to be for internal use only, and
the pointer type will eventually have to change to remove UB from
ilist_iterator. Instead, check the iterator before it has been
invalidated.
llvm-svn: 261497
|
|
|
|
|
|
|
|
|
|
|
| |
Stop using `getNodePtrUnchecked()` when building IR. Eventually a
dereference will be required to get at the downcast node, since the
iterator will only store an `ilist_node_base` of some sort.
This should have no functionality change for now, but is a path towards
removing some more UB from ilist.
llvm-svn: 261495
|
|
|
|
| |
llvm-svn: 261494
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`ilist_iterator<NodeTy>::getNodePtrUnchecked()` is documented as being
for internal use only, but CodeGenPrepare was using it anyway. This
code relies on pulling out the `Value*` pointer even after the lifetime
of the iterator is over. But having this pointer available in
ilist_iterator depends on UB in the first place.
Instead, safely pull out the `Value*` when the iterator is alive and
stop using the internal-only API.
There should be no functionality change here.
llvm-svn: 261493
|
|
|
|
|
|
|
|
| |
Add support for the case where we have a consecutive load (which must include the first + last elements) with a mixture of undef/zero elements. We load the vector and then apply a shuffle to clear the zero'd elements.
Differential Revision: http://reviews.llvm.org/D17297
llvm-svn: 261490
|
|
|
|
|
|
| |
This addresses post-review comments from Sanjoy Das for r261485.
llvm-svn: 261486
|
|
|
|
|
|
|
|
|
|
| |
Before this patch simplified SCEV expressions for PHI nodes were only returned
the very first time getSCEV() was called, but later calls to getSCEV always
returned the non-simplified value, which had "temporarily" been stored in the
ValueExprMap, but was never removed and consequently blocked the caching of the
simplified PHI expression.
llvm-svn: 261485
|
|
|
|
| |
llvm-svn: 261484
|
|
|
|
|
|
|
|
|
| |
Originally part of:
http://reviews.llvm.org/D17485
We need this when simplifying masked memory ops too.
llvm-svn: 261483
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Rename `"skylake"` == SkylakeServerProc to `"skylake-avx512"`
- Change `"skylake"` to denote SkylakeClientProc
- Fix the detection of cpu family 6 and model 94 to be
SkylakeClientProc instead of SkylakeServerProc
- Remove the `"cnl"` for CannonLake
Reviewers: craig.topper, delena
Subscribers: zansari, echristo, qcolombet, RKSimon, spatel, DavidKreitzer, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D17090
llvm-svn: 261482
|
|
|
|
|
|
|
| |
This is inspired by PR24804 -- had this assert been there before,
isolating the root cause for PR24804 would have been far easier.
llvm-svn: 261481
|
|
|
|
|
|
| |
r261457 handles CopyToReg nodes with flag results in LowerCopyToReg, which was causing the SelectionDAGNodes assert.
llvm-svn: 261479
|
|
|
|
| |
llvm-svn: 261465
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a common parent `ConstantData` to the constants that have no
operands. These are guaranteed to represent abstract data that is in no
way tied to a specific Module.
This is a good cleanup on its own. It also makes it simpler to disallow
RAUW (and factor away use-lists) on these constants in the future. (I
have some experimental patches that make RAUW illegal on ConstantData,
and they seem to catch a bunch of bugs...)
llvm-svn: 261464
|