These tests were clearly auto-generated when they were converted to
FileCheck back in r80019 (2009), but we didn't have a fancy script to
keep them up to date then. I've reviewed the diff, and we should be
generating the exact same code sequences we used to.
After this, I plan to commit a change that changes our output slightly,
but in a way that is still correct. It will generate a large diff, and I
want it to be clearly correct, so I am regenerating these checks in
preparation for that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338928 91177308-0d34-0410-b5e6-96231b3b80d8
- Remove -asm-verbose=0 from every llc command. The tests still pass.
- Reorder the RUN lines to match CHECKs.
- Use -LABEL like update_llc_test_checks.py does.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338927 91177308-0d34-0410-b5e6-96231b3b80d8
Put the LLVM IR at the bottom of the function instead of the top. In my
next patch, I will run update_llc_test_checks.py on this file, and I
want to only highlight the diffs in the CHECK lines. Hopefully by doing
this change first, the patch will be more understandable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338926 91177308-0d34-0410-b5e6-96231b3b80d8
At one point in time acquire implied mayLoad and mayStore as did release. Thus we needed separate pseudos that also carried that property. This appears to no longer be the case. I believe it was changed in 2012 with a comment saying that atomic memory accesses are marked volatile which preserves the ordering.
So from what I can tell we shouldn't need additional pseudos since they aren't carry any flags that are different from the normal instructions. The only thing I can think of is that we may consider them for load folding candidates in the peephole pass now where we didn't before. If that's important hopefully there's something in the memory operand we can check to prevent the folding without relying on pseudo instructions.
Differential Revision: https://reviews.llvm.org/D50212
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338925 91177308-0d34-0410-b5e6-96231b3b80d8
Add a parameter for testing specifically for
sNaNs - at least one instruction pattern on AMDGPU
needs to check specifically for this.
Also handle more cases, and add a target hook
for custom nodes, similar to the hooks for known
bits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338910 91177308-0d34-0410-b5e6-96231b3b80d8
Clang uses "ctpop & 1" to implement __builtin_parity. If the popcnt instruction isn't supported this generates a large amount of code to calculate the population count. Instead we can bisect the data down to a single byte using xor and then check the parity flag.
Even when popcnt is supported, its still a good idea to split 64-bit data on 32-bit targets using an xor in front of a single popcnt. Otherwise we get two popcnts and an add before the and.
I've specifically targeted this at the sizes supported by clang builtins, but we could generalize this if we think that's useful.
Differential Revision: https://reviews.llvm.org/D50165
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338907 91177308-0d34-0410-b5e6-96231b3b80d8
Basic pattern that leaves an unnecessary select on a rotation by zero result. This variant is trivial - the more general case with a compare+branch to prevent execution of undefined shifts is more tricky.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338833 91177308-0d34-0410-b5e6-96231b3b80d8
There are a lot of permutations of types here generating a lot of patterns in the isel table. It's more efficient to just ReplaceUses and RemoveDeadNode from the Select function.
The test changes are because we have a some shuffle patterns that have a bitcast as their root node. But the behavior is identical to another instruction whose pattern doesn't start with a bitcast. So this isn't a functional change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338824 91177308-0d34-0410-b5e6-96231b3b80d8
Move all the patterns to X86InstrVecCompiler.td so we can keep SSE/AVX/AVX512 all in one place.
To save some patterns we'll use an existing DAG combine to convert f128 fand/for/fxor to integer when sse2 is enabled. This allows use to reuse all the existing patterns for v2i64.
I believe this now makes SHA instructions the only case where VEX/EVEX and legacy encoded instructions could be generated simultaneously.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338821 91177308-0d34-0410-b5e6-96231b3b80d8
If the producing instruction is legacy encoded it doesn't implicitly zero the upper bits. This is important for the SHA instructions which don't have a VEX encoded version. We might also be able to hit this with the incomplete f128 support that hasn't been ported to VEX.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338812 91177308-0d34-0410-b5e6-96231b3b80d8
This makes them consistent with i8/i32/i64. Which still seems to be more aggressive on folding than icc, gcc, or MSVC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338795 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
I encountered some problems with SIFixWWMLiveness when WWM is in a loop:
1. It sometimes gave invalid MIR where there is some control flow path
to the new implicit use of a register on EXIT_WWM that does not pass
through any def.
2. There were lots of false positives of registers that needed to have
an implicit use added to EXIT_WWM.
3. Adding an implicit use to EXIT_WWM (and adding an implicit def just
before the WWM code, which I tried in order to fix (1)) caused lots
of the values to be spilled and reloaded unnecessarily.
This commit is a rework of SIFixWWMLiveness, with the following changes:
1. Instead of considering any register with a def that can reach the WWM
code and a def that can be reached from the WWM code, it now
considers three specific cases that need to be handled.
2. A register that needs liveness over WWM to be synthesized now has it
done by adding itself as an implicit use to defs other than the
dominant one.
Also added the following fixmes:
FIXME: We should detect whether a register in one of the above
categories is already live at the WWM code before deciding to add the
implicit uses to synthesize its liveness.
FIXME: I believe this whole scheme may be flawed due to the possibility
of the register allocator doing live interval splitting.
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D46756
Change-Id: Ie7fba0ede0378849181df3f1a9a7a39ed1a94a94
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338783 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This fixes a problem where a load from global+idx generated incorrect
code on <=gfx7 when the index is divergent.
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D47383
Change-Id: Ib4d177d6254b1dd3f8ec0203fdddec94bd8bc5ed
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338779 91177308-0d34-0410-b5e6-96231b3b80d8
This will remove suboptimal branching from the generated ll/sc loops.
The extra simplification pass affects a lot of testcases, which have
been modified to accommodate this change: either by modifying the
test to become immune to the CFG simplification, or (less preferablt)
by adding option -hexagon-initial-cfg-clenaup=0.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338774 91177308-0d34-0410-b5e6-96231b3b80d8
Rather than allowing invalid bitcasts to be lowered to wasm
call instructions that won't validate, generate wrappers that
contain unreachable thereby delaying the error until runtime.
Differential Revision: https://reviews.llvm.org/D49517
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338744 91177308-0d34-0410-b5e6-96231b3b80d8
These instructions perform the same operation, but the semantic of which operand is destroyed is reversed. If the same register is used as both operands we can change the execution domain without worrying about this difference.
Unfortunately, this really only works in cases where the input register is killed by the instruction. If its not killed, the two address isntruction pass inserts a copy that will become a move instruction. This makes the instruction use different physical registers that contain the same data at the time the unpck/movhlps executes. I've considered using a unary pseudo instruction with tied operand to trick the two address instruction pass. We could then expand the pseudo post regalloc to get the same physical register on both inputs.
Differential Revision: https://reviews.llvm.org/D50157
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338735 91177308-0d34-0410-b5e6-96231b3b80d8
In expansion of FCOPYSIGN, the shift node is missing when the two
operands of FCOPYSIGN are of the same size. We should always generate
shift node (if the required shift bit is not zero) to put the sign
bit into the right position, regardless of the size of underlying
types.
Differential Revision: https://reviews.llvm.org/D49973
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338665 91177308-0d34-0410-b5e6-96231b3b80d8
Adding the FP_ROUND nodes when combining FP_TO_[SU]INT of elements
feeding a BUILD_VECTOR into an FP_TO_[SU]INT of the built vector
loses precision. This patch removes the code that adds these nodes
to true f64 operands. It also adds patterns required to ensure
the code is still vectorized rather than converting individual
elements and inserting into a vector.
Fixes https://bugs.llvm.org/show_bug.cgi?id=38342
Differential Revision: https://reviews.llvm.org/D50121
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338658 91177308-0d34-0410-b5e6-96231b3b80d8
Do the same handling for external symbols that we do for jump table
symbols and global values.
Fixes one of the cases in PR38385
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338651 91177308-0d34-0410-b5e6-96231b3b80d8
Mutate the node type during selection when it
doesn't matter. This avoids an intermediate bitcast
node on targets with legal i16/f16.
Also fixes missing output modifiers on v_cvt_pkrtz_f32_f16,
which I assume are OK.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338619 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes annoying limitations when writing tests.
Also remove more leftover code for manually scalarizing arguments
and return values.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338618 91177308-0d34-0410-b5e6-96231b3b80d8
We now emit a move of -1 before the cmov and do the addition after the cmov just like the case with an extra addition.
This may be slightly worse for code size, but is more consistent with other compilers. And we might be able to hoist the mov -1 outside of loops.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338613 91177308-0d34-0410-b5e6-96231b3b80d8
We previously had tests for "__builtin_ffs + 5", but the SelectinoDAG without an extra addition came out slightly different.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338612 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
D25878, which added support for !absolute_symbol for normal X86 ISel,
did not add support for materializing references to absolute symbols for
X86 FastISel. This causes build failures because FastISel generates
PC-relative relocations for absolute symbols. Fall back to normal ISel
for references to !absolute_symbol GVs. Fix for PR38200.
Reviewers: pcc, craig.topper
Reviewed By: pcc
Subscribers: hiraditya, llvm-commits, kcc
Differential Revision: https://reviews.llvm.org/D50116
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338599 91177308-0d34-0410-b5e6-96231b3b80d8
Aditya Nandakumar