| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 286255
|
| |
|
|
| |
llvm-svn: 286253
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
not bytes.
Summary: In addition, the branch instructions will have proper BB destinations, not offsets, like before.
Reviewers: asl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D23718
llvm-svn: 286252
|
| |
|
|
| |
llvm-svn: 286241
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed an issue with vector usage of TargetLowering::isConstTrueVal / TargetLowering::isConstFalseVal boolean result matching.
The comment said we shouldn't handle constant splat vectors with undef elements. But the the actual code was returning false if the build vector contained no undef elements....
This patch now ignores the number of undefs (getConstantSplatNode will return null if the build vector is all undefs).
The change has also unearthed a couple of missed opportunities in AVX512 comparison code that will need to be addressed.
Differential Revision: https://reviews.llvm.org/D26031
llvm-svn: 286238
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These are good candidates for jump threading. This enables later opts
(such as InstCombine) to combine instructions from the selects with
instructions out of the selects. SimplifyCFG will fold the select
again if unfolding wasn't worth it.
Patch by James Molloy and Pablo Barrio.
Reviewers: rengolin, haicheng, sebpop
Subscribers: jojo, jmolloy, llvm-commits
Differential Revision: https://reviews.llvm.org/D26391
llvm-svn: 286236
|
| |
|
|
|
|
|
|
|
|
| |
This patch avoids scalarization of CTLZ by instead expanding to use CTPOP (ref: "Hacker's Delight") when the necessary operations are available.
This also adds the necessary cost models for X86 SSE2 targets (the main beneficiary) to ensure vectorization only happens when its useful.
Differential Revision: https://reviews.llvm.org/D25910
llvm-svn: 286233
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Under -enable-unsafe-fp-math, SELECT_CC lowering in AArch64
transforms floating point comparisons of the form "a == 0.0 ? 0.0 : x" to
"a == 0.0 ? a : x". But it incorrectly assumes that 'x' and 'a' have
the same type which can lead to a wrong CSEL node that crashes later
due to nonsensical copies.
Differential Revision: https://reviews.llvm.org/D26394
llvm-svn: 286231
|
| |
|
|
| |
llvm-svn: 286230
|
| |
|
|
|
|
| |
and regenerate. This will make a change in a future patch easier to see. NFC
llvm-svn: 286216
|
| |
|
|
| |
llvm-svn: 286185
|
| |
|
|
|
|
|
|
|
|
| |
Self-referencing PHI nodes need their destination operands to be constrained
because nothing else is likely to do so. For now we just pick a register class
naively.
Patch mostly by Ahmed again.
llvm-svn: 286183
|
| |
|
|
| |
llvm-svn: 286174
|
| |
|
|
| |
llvm-svn: 286173
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
copies
Codegen prepare sinks comparisons close to a user is we have only one register
for conditions. For AMDGPU we have many SGPRs capable to hold vector conditions.
Changed BE to report we have many condition registers. That way IR LICM pass
would hoist an invariant comparison out of a loop and codegen prepare will not
sink it.
With that done a condition is calculated in one block and used in another.
Current behavior is to store workitem's condition in a VGPR using v_cndmask
and then restore it with yet another v_cmp instruction from that v_cndmask's
result. To mitigate the issue a forward propagation of a v_cmp 64 bit result
to an user is implemented. Additional side effect of this is that we may
consume less VGPRs in a cost of more SGPRs in case if holding of multiple
conditions is needed, and that is a clear win in most cases.
llvm-svn: 286171
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
With this we get a new field in the YAML record if the value being
streamed out has a debug location. For examples, please see the changes
to the tests.
This is then used in opt-viewer to display a link for the callee
function in the inlining remarks.
Differential Revision: https://reviews.llvm.org/D26366
llvm-svn: 286169
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Some vector loads and stores generated from AArch64 intrinsics alias each other
unnecessarily, preventing better scheduling. We just need to transfer memory
operands during lowering.
Reviewers: mcrosier, t.p.northover, jmolloy
Subscribers: aemerson, rengolin, llvm-commits
Differential Revision: https://reviews.llvm.org/D26313
llvm-svn: 286168
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Because we shift the stack pointer by an unknown amount, we need an
additional pointer. In the case where we have variable-size objects
as well, we can't reuse the frame pointer, thus three pointers.
Patch by Jacob Gravelle
Differential Revision: https://reviews.llvm.org/D26263
llvm-svn: 286160
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In some specific scenarios with well understood operand bundle types
(like `"deopt"`) it may be possible to go ahead and convert recursion to
iteration, but TailRecursionElimination does not have that logic today
so avoid doing the right thing for now.
I need some input on whether `"funclet"` operand bundles should also
block tail recursion elimination. If not, I'll allow TRE across calls
with `"funclet"` operand bundles and add a test case.
Reviewers: rnk, majnemer, nlewycky, ahatanak
Subscribers: mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D26270
llvm-svn: 286147
|
| |
|
|
|
|
|
|
|
|
| |
accesses, LLVM part
Although rare, atomic accesses to floating-point types seem to be valid, i.e. `%a = load atomic float ...`. The TSan instrumentation pass however tries to emit inttoptr, which is incorrect, we should use a bitcast here. Anyway, IRBuilder already has a convenient helper function for this.
Differential Revision: https://reviews.llvm.org/D26266
llvm-svn: 286135
|
| |
|
|
|
|
|
| |
The comment explaining why this was necessary is incorrect
in its description of v_cmp's behavior for inactive workitems.
llvm-svn: 286134
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If the branch was on a read-undef of vcc, passes that used
analyzeBranch to invert the branch condition wouldn't preserve
the undef flag resulting in a verifier error.
Fixes verifier failures in a future commit.
Also fix verifier error when inserting copy for vccz
corruption bug.
llvm-svn: 286133
|
| |
|
|
|
|
|
|
|
| |
Argument evaluation order is one of the edge cases where Clang differs
from GCC, yielding different IR depending on which compiler LLVM was
built with. Make the order deterministic and tune the test to actually
verify the order instead of trying to hide it.
llvm-svn: 286126
|
| |
|
|
|
|
|
|
| |
gets to ISel.
Differential Revision: https://reviews.llvm.org/D26292
llvm-svn: 286119
|
| |
|
|
|
|
|
|
| |
This was reverted at r285866 because there was a crash handling a scalar
select of vectors. I added a check for that pattern and a test case based
on the example provided in the post-commit thread for r285732.
llvm-svn: 286113
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
asm register selection on AArch64.
Without this patch, register allocation for the example below fails.
define half @test(half %a1, half %a2) #0 {
entry:
%0 = tail call half asm "sqrshl ${0:h}, ${1:h}, ${2:h}", "=w,w,w" (half %a1, half %a2) #1
ret half %0
}
Patch by Florian Hahn.
Differential Revision: https://reviews.llvm.org/D25080
llvm-svn: 286111
|
| |
|
|
|
|
|
|
| |
This feature has been disabled for some time now, so remove cruft.
Differential Revision: https://reviews.llvm.org/D26248
llvm-svn: 286110
|
| |
|
|
|
|
|
|
| |
actually affect memory.
Differential Revision: https://reviews.llvm.org/D26252
llvm-svn: 286108
|
| |
|
|
|
|
|
|
|
|
| |
When the base register (register pointing to the jump table) is the PC, we expect the jump table to directly follow the jump sequence with no intervening padding.
If there is intervening padding, the calculated offsets will not be correct. One solution would be to account for any padding in the emitted LDRB instruction, but at the moment we don't support emitting MCExprs for the load offset.
In the meantime, it's correct and only a slight amount worse to just move the padding up, from just before the jump table to just before the jump instruction sequence. We can do that by emitting code alignment before the jump sequence, as we know the number of instructions in the sequence is always 4.
llvm-svn: 286107
|
| |
|
|
| |
llvm-svn: 286105
|
| |
|
|
|
|
| |
cpu/triple duplication
llvm-svn: 286104
|
| |
|
|
|
|
|
|
| |
selects and native zext/sext.
This mostly reuses earlier autoupgrade support for the sse and avx equivalents. Just needed to add the code to add the select.
llvm-svn: 286092
|
| |
|
|
|
|
| |
legacy intrinsics and a select.
llvm-svn: 286089
|
| |
|
|
|
|
|
|
|
|
|
| |
This handles the last case of the builtin function calls that we would
generate code which differed from Microsoft's ABI. Rather than
generating a call to `__pow{d,s}i2` we now promote the parameter to a
float or double and invoke `powf` or `pow` instead.
Addresses PR30825!
llvm-svn: 286082
|
| |
|
|
| |
llvm-svn: 286075
|
| |
|
|
|
|
| |
In preparation for demandedelts support
llvm-svn: 286074
|
| |
|
|
|
|
| |
upgrade them to a select and the older AVX2 intrinsic.
llvm-svn: 286073
|
| |
|
|
|
|
| |
Instead upgrade them to a select and the older SSE/AVX2 intrinsic.
llvm-svn: 286072
|
| |
|
|
| |
llvm-svn: 286071
|
| |
|
|
|
|
| |
in xmm. Instead upgrade them to a select and the older SSE/AVX2 intrinsic.
llvm-svn: 286070
|
| |
|
|
|
|
| |
already exists in the avx512f test file.
llvm-svn: 286069
|
| |
|
|
|
|
| |
In preparation for demandedelts support
llvm-svn: 286068
|
| |
|
|
|
|
| |
for these test cases will be improved for AVX512 in a future commit.
llvm-svn: 286063
|
| |
|
|
|
|
| |
addr:)) -> VCVTPS2PDZ128rm
llvm-svn: 286059
|
| |
|
|
|
|
| |
-show-mc-encoding to show where we aren't using EVEX instructions.
llvm-svn: 286058
|
| |
|
|
|
|
| |
instruction when available.
llvm-svn: 286057
|
| |
|
|
|
|
| |
they can use EVEX instructions when available.
llvm-svn: 286056
|
| |
|
|
|
|
| |
see when VEX or EVEX encoded instructions are being emitted. Make sure the tests all have an avx2 command line and an skx command line.
llvm-svn: 286055
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
valid int64_t to the set.
Summary:
SmallSetVector uses DenseSet, but that means we need to reserve some
values for the empty and tombstone keys.
It seems to me we should have a general way to let us store full-range
ints inside of DenseSets, and furthermore that we probably shouldn't
silently let you add ints into DenseSets without explicitly promising
that they're in range. But that's a battle for another day; for now,
just fix this code, since we currently do something Very Bad when
compiling ffmpeg.
Fixes PR30914.
Reviewers: jeremyhu
Subscribers: llvm-commits, mzolotukhin
Differential Revision: https://reviews.llvm.org/D26323
llvm-svn: 286038
|
| |
|
|
| |
llvm-svn: 286009
|