RISC-V vector instruction has register overlapping constraint for certain
instructions, and will cause illegal instruction trap if violated, we use
early clobber to model this constraint, but it can't prevent register allocator
allocated same or overlapped if the input register is undef value, so convert
IMPLICIT_DEF to temporary pseudo could prevent that happen, it's not best way
to resolve this. Ideally we should model the constraint right, but before we
model the constraint right, it's the approach to prevent that happen.
See also: https://github.com/llvm/llvm-project/issues/50157
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D129735
Ideally `addu16i.d` could be paired with `{ld,st}ptr` for faster memory
accesses with 32-bit-aligned offsets (it was designed for this purpose),
but it would require more work and the original use case (GP-relative
accesses) does not exist any more with the current LoongArch psABI.
It could still be used for accelerating additions of certain constants
though, which is what this patch intends to do.
Reviewed By: SixWeining, gonglingqin
Differential Revision: https://reviews.llvm.org/D143710
D139710 has added a metric to increase schedule's ILP while
staying within the same occupancy. Do not bother to apply this
metric to a region which is known to have spilling, it may result
in spilling to reappear after the previous stage and will do no
good if we already spilling anyway. It may also reduce compile
time a bit for such regions.
Fixes: SWDEV-377300
Differential Revision: https://reviews.llvm.org/D143934
This doesn't make sense as an option. fneg and fabs are bit
preserving by definition. If a target has some fneg or fabs
instruction that are not bitpreserving it's incorrect to lower
fneg/fabs to use it.
Requiring a bitcast to exist was unhelpful. The most basic cases
are always going to be a CopyFromReg or load, so they would need
a new cast inserted. Don't require a bitcast if it's a free
operation. I don't think this logic makes particularly much sense
(it seems to be imparting special interpretation of bitcast), but
this needs to be in sync with foldSignChangeInBitcast.
We should also get rid of this hasBitPreservingFPLogic hook. fabs/fneg
are bitpreserving or incorrectly implemented, so this should just be a
regular legality check.
This fixes the combination of two things:
* Placing a BTI after calls to a returns twice function like setjmp.
This allows the setjmp to return with a br instead of a ret.
* Straight line speculation mitigations that replace BLR with a BL
to a thunk that does the mitigation, and then goes to the original
target.
Originally I marked AArch64call_bti as requiring that SLS mitigation
be disabled. This caused a crash when you tried to codegen with both.
Since CALL_BTI tried to match with AArch64call_bti but could not.
This change does 2 things:
* Follow the pattern set by AArch64call and add 2 patterns for
AArch64call_bti. One with no IP (interprocedural) registers,
and one with. For SLS mitigation on and off respectively.
* Modify the sls hardening pass to iterate through bundled
instructions, as the AArch64 KCFI pass does.
Since there is a 1:1 replacement of the BLR with a BL,
the bundle remains intact. This is checked with an MIR test.
The ir -> asm testing is updated to add runs with the sls
mitigation enabled.
Reviewed By: kristof.beyls, pzheng
Differential Revision: https://reviews.llvm.org/D143915
While working on D143731 I hit a case where a build_vector with 2 undef operands could be generated (with one undef hidden behind a bitcast).
That made `reduceBuildVecTruncToBitCast` crash because it seems to assume there is at least one good operand.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D143886
Enable __arithmetic_fence and fprotect-parens on AArch64.
Test plan: ninja check-clang check-clang-tools check-llvm
Differential revision: https://reviews.llvm.org/D143781
The vsetvli insertion pass can replace it with MU if needed by
a using instruction. The vsetvli insertion pass will not convert
MU to MA so we need to start at MA.
Reviewed By: eopXD
Differential Revision: https://reviews.llvm.org/D143790
Some subtargets use architected SGPRs for workgroup
IDs instead of the regular SGPRs. This patch enables
the support for the same and is guarded under the
subtarget feature FeatureArchitectedSGPRs.
Reviewed By: foad
Differential Revision: https://reviews.llvm.org/D143707
Remove a dead masked store if another one has the same base pointer and mask or
the following store has all true constant mask and size if equal or bigger to
the first store.
Differential Revision: https://reviews.llvm.org/D143069
Two of the float materialization patterns use the VSSRC regsiter class. This
register class is not available before Power 8. The patterns will stay the same
for Power 8 and up but must use the class F4RC for Power 7 and earlier.
This patch fixes those patterns.
Reviewed By: nemanjai, amyk, #powerpc
Differential Revision: https://reviews.llvm.org/D142120
When both v8i64 and v4f16 are not legal in a v8i64->v8f16 conversion, legalizer will breaks it into v8i64->v4i64->v4f32->v8f32->v8f16.
Given we support v4i64->v8f16, we can combine them with a shuffle instruction.
Reviewed By: LuoYuanke
Differential Revision: https://reviews.llvm.org/D143872
The mid end will reassociate sub(sub(x, m1), m2) to sub(x, add(m1, m2)). This
reassociates it back to allow the creation of more mls instructions.
Differential Revision: https://reviews.llvm.org/D143143
D142712 added tests for when both lse2 and lse128 are available, but
in practice there is no way to enable LSE128 without LSE2 from clang:
LSE128 is a v9 only feature and LSE2 has been mandatory since v8.4,
and +/-lse2 can not be specified on the clang command line.
Therefore it makes more sense that lse2+lse128 should emit lse128
instructions, otherwise they will not be emitted at all.
It also makes sense to remove the lse128-only backend tests if that set
of attributes is never set by the frontend.
Differential Revision: https://reviews.llvm.org/D143506
With the NPM, we're now defaulting to preserving LCSSA, so a couple
of tests have changed slightly.
Differential Revision: https://reviews.llvm.org/D140982
Noticed while working on Issue #59867 and Issue #53419 - there's still more to do here, but for "all vector" comparisons, we should try to cast to a scalar integer for sub-128bit types
This reverts commit c52255d26a23df6ecf09f60ca3e3615467f16bbe.
That commit caused certain files (in ffmpeg, libvpx and libaom) to hang
while compiling, see https://reviews.llvm.org/D143143 for repro.
We should be able to use load(literal) to access constant pool under
the tiny code model.
Reviewed By: aemerson
Differential Revision: https://reviews.llvm.org/D132536
getFauxShuffleMask can't handle ISD::TRUNCATE itself as it can't handle inputs that are larger than the output
Another step towards removing combineX86ShuffleChainWithExtract
