TableGen is still getting miscompiled on PPC buildbots.
Sent a mail with request for help.
This reverts commit 3c4d2a03968ccf5889bacffe02d6fa2443b0260f.
This is a recommit of cf624b23bc5d5a6161706d1663def49380ff816a,
which was reverted in 5cfc22cafe3f2465e0bb324f8daba82ffcabd0df,
because the cut-off on the number of vector elements was not low enough,
and it triggered both SDAG SDNode operand number assertions,
and caused compile time explosions in some cases.
Let's try with something really *REALLY* conservative first,
just to get somewhere, and try to bump it (to 64/128) later.
FIXME: should this respect TTI reg width * num vec regs?
Original commit message:
Now, there's a big caveat here - these bytes
are abstract bytes, not the i8 we have in LLVM,
so strictly speaking this is not exactly legal,
see e.g. https://github.com/AliveToolkit/alive2/issues/860
^ the "bytes" "could" have been a pointer,
and loading it as an integer inserts an implicit ptrtoint.
But at the same time,
InstCombine's `InstCombinerImpl::SimplifyAnyMemTransfer()`
would expand a memtransfer of 1/2/4/8 bytes
into integer-typed load+store,
so this isn't exactly a new problem.
Note that in memory, poison is byte-wise,
so we really can't widen elements,
but SROA seems to be inconsistent here.
Fixes#59116.
As apparent in the newly-added test, provided in:
cf624b23bc (commitcomment-90836329),
we should be more careful with handling wider vectors,
or we will assert later on.
add can always be compressed to c.add if one of the sources is the
same as the destination.
The same is not true for c.addw where the registers need to be x8-x15.
Compressed instructions usually require one of the source registers
to also be the source register. The register allocator doesn't have
that bias on its own.
This patch adds register allocation hints to introduce this bias.
I've started with ADDI, ADDIW, and SLLI. These all have a 5-bit
field for the register. If the source and dest register are the
same they are guaranteed to compress as long as the immediate is
also 6 bits.
This code was inspired by similar code from the SystemZ target.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D138242
We're using lowerShuffleAsPermuteAndUnpack, which can probably be improved to handle 256/512-bit types pretty easily.
First step towards trying to address the poor vector-shuffle-sse4a.ll pre-SSSE3 codegen mentioned on D127115
This patch reduces the number of unpredictable branches
(select (x < 0), y, z) -> x >> (XLEN - 1) & (y - z) + z
(select (x >= 0), y, z) -> x >> (XLEN - 1) & (z - y) + y
Reviewed By: craig.topper, reames
Differential Revision: https://reviews.llvm.org/D137949
Use a dyn_cast<> to IntrinsicInst and an enum compare instead.
While touching this code also re-generate the test to use positive check
lines instead of negative ones and remove some unneeded metadata.
Reviewed By: yonghong-song
Differential Revision: https://reviews.llvm.org/D138565
If one of the AND operands is a setcc then we're implicitly zeroing the upper mask bits
Similar pattern to regressions identified in D127115 (masked comparisons)
This allows DemandedBits to see that the SVE count intrinsics (CNTB,
CNTH, CNTW, CNTD) sans multiplier will only ever produce small
positive integers. The maximum value you could get here is 256, which
is CNTB on a machine with a 2048bit vector size (the maximum for SVE).
Using this various redundant operations (zexts, sexts, ands, ors, etc)
can be eliminated.
Differential Revision: https://reviews.llvm.org/D138424
When a module contains more than one function, we should update debugify metadata
by increasing the number of variables in the function rather than overwritting it.
Previous revert issue is fixed: I forgot to strip all x86-related info from the
test.
Differential Revision: https://reviews.llvm.org/D136949
To generate code compatible to streaming mode:
- enable custom lowering for VSETCC, needed for (fp-vselect.ll, int-vselect.ll).
Differential Revision: https://reviews.llvm.org/D138519
When a module contains more than one function, we should update debugify metadata
by increasing the number of variables in the function rather than overwritting it.
Differential Revision: https://reviews.llvm.org/D136949
A `select i1 %c, i1 true, i1 %d` is just an or and a `select i1 %c, i1 %d, i1 false`
is just an and. There are better treated as such in the logic of SelectOpt, allowing
the backend to optimize them to and/or directly.
Differential Revision: https://reviews.llvm.org/D138490
We don't strip llvm.mir.debugify metadata in `llvm::stripDebugifyMetadata`. This
may lead to incorrect number of lines and variables in the metadata when we run
debugify twice, e.g. -run-pass=mir-debugify,...,mir-strip-debug,...,mir-debugify.
Differential Revision: https://reviews.llvm.org/D138417
So we have the opportunity to fold splat into .vx instruction as what
D101138 has done. If failed, we can select zero-stride vector load
again.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D138101
When reading or writing a register that does not conform to the size of a
hardware register, an error message is generated instead of a compiler crash.
Differential Revision: https://reviews.llvm.org/D138008
vperm instruction requires the data to be in the Altivec registers, if one of
the vector operands is not used after this vperm instruction then it can be
substituted by xxperm which doubles the number of available registers.
Reviewed By: stefanp
Differential Revision: https://reviews.llvm.org/D133700
* For case bcmp9, there is extras AND and EXTEND int the chain of OR/XOR,
which prevent the transform, so enable the optimize before legalization.
* The key IR frag related:
t37: i32,ch = load<(load (s8) from %ir.4), anyext from i8> t0, t11, undef:i64
t12: i64 = add t4, Constant:i64<8>
t38: i32,ch = load<(load (s8) from %ir.5), anyext from i8> t0, t12, undef:i64
t39: i32 = xor t37, t38
t40: i64 = any_extend t39
t42: i64 = and t40, Constant:i64<255>
Depends on D138398 to fix combine_setcc_glue
Reviewed By: dmgreen, bcl5980
Differential Revision: https://reviews.llvm.org/D137936
I noticed a an assertion error when building MIPS code that loaded from
NULL. Loading from NULL ends up being a load with maximum alignment, and
due to integer truncation the value maximum was interpreted as 0 and the
assertion in MipsDAGToDAGISel::Select() failed. This previously happened
to work, but the maximum alignment was increased in
df84c1fe78130a86445d57563dea742e1b85156a, so it no longer fits into a 32
bit integer.
Instead of just fixing the one MIPS case, this patch removes all uses of
the deprecated getAlignment() call and replaces them with getAlign().
Differential Revision: https://reviews.llvm.org/D138420
global/scratch_load will return in order they are issued. No
need to insert a s_waitcnt for WAW hazard.
Reviewed By: foad
Differential Revision: https://reviews.llvm.org/D138476
A scalar which exceeds 4 bytes should be returned via stack, other
than via registers, on an AVRTiny device.
Reviewed By: aykevl
Differential Revision: https://reviews.llvm.org/D138201
or (xor x, y), x --> or x, y
or (xor x, y), y --> or x, y
or (xor x, y), (and x, y) --> or x, y
or (xor x, y), (or x, y) --> or x, y
Reviewed By: foad
Differential Revision: https://reviews.llvm.org/D138401
Now, there's a big caveat here - these bytes
are abstract bytes, not the i8 we have in LLVM,
so strictly speaking this is not exactly legal,
see e.g. https://github.com/AliveToolkit/alive2/issues/860
^ the "bytes" "could" have been a pointer,
and loading it as an integer inserts an implicit ptrtoint.
But at the same time,
InstCombine's `InstCombinerImpl::SimplifyAnyMemTransfer()`
would expand a memtransfer of 1/2/4/8 bytes
into integer-typed load+store,
so this isn't exactly a new problem.
Note that in memory, poison is byte-wise,
so we really can't widen elements,
but SROA seems to be inconsistent here.
Fixes#59116.
