Ignorable operands don't impact instruction's behavior, we can safely do CSE on
the instruction.
It is split from D130919. It has big impact to some AMDGPU test cases.
For example in atomic_optimizations_raw_buffer.ll, when trying to check if the
following instruction can be CSEed
%37:vgpr_32 = V_MOV_B32_e32 0, implicit $exec
Function isCallerPreservedOrConstPhysReg is called on operand "implicit $exec",
this function is implemented as
- return TRI.isCallerPreservedPhysReg(Reg, MF) ||
+ return TRI.isCallerPreservedPhysReg(Reg, MF) || TII.isIgnorableUse(MO) ||
(MRI.reservedRegsFrozen() && MRI.isConstantPhysReg(Reg));
Both TRI.isCallerPreservedPhysReg and MRI.isConstantPhysReg return false on this
operand, so isCallerPreservedOrConstPhysReg is also false, it causes LLVM failed
to CSE this instruction.
With this patch TII.isIgnorableUse returns true for the operand $exec, so
isCallerPreservedOrConstPhysReg also returns true, it causes this instruction to
be CSEed with previous instruction
%14:vgpr_32 = V_MOV_B32_e32 0, implicit $exec
So I got different result from here. AMDGPU's implementation of isIgnorableUse
is
bool SIInstrInfo::isIgnorableUse(const MachineOperand &MO) const {
// Any implicit use of exec by VALU is not a real register read.
return MO.getReg() == AMDGPU::EXEC && MO.isImplicit() &&
isVALU(*MO.getParent()) && !resultDependsOnExec(*MO.getParent());
}
Since the operand $exec is not a real register read, my understanding is it's
reasonable to do CSE on such instructions.
Because more instructions are CSEed, so I get less instructions generated for
these tests.
Differential Revision: https://reviews.llvm.org/D137222
Generic add and sub with carry are now legalized in a way to explicitly calculate carry/borrow output. i.e
%6:_(s64), %7:_(s1) = G_UADDO %0, %1
becomes,
%13:_(s32), %14:_(s1) = G_UADDO %2, %4
%15:_(s32), %16:_(s1) = G_UADDE %3, %5, %14
%6:_(s64) = G_MERGE_VALUES %13(s32), %15(s32)
%7:_(s1) = G_ICMP intpred(ult), %6(s64), %1
Here G_MERGE and G_ICMP instructions are redundant for recalculating carry output. (Similar case for sub with borrow)
This change fix this.
Reviewed By: arsenm, #amdgpu
Differential Revision: https://reviews.llvm.org/D137932
This change provides an implementation of the XVentanaCondOps vendor extension. This extension is defined in version 1.0.0 of the VTx-family custom instructions specification (https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.0/ventana-custom-extensions-v1.0.0.pdf) by Ventana Micro Systems.
In addition to the technical contribution, this change is intended to be a test case for our vendor extension policy.
Once this lands, I plan to use this extension to prototype selection lowering to conditional moves. There's an RVI proposal in flight, and the expectation is that lowering to these and the new RVI instructions is likely to be substantially similar.
Differential Revision: https://reviews.llvm.org/D137350
This test is not particularly useful for testing complex deinterleaving,
especially due to f64 muls not being supported in mve. The test is
being removed as it's hitting an unrelated pre-existing condition
regarding register spilling.
Adds the Complex Deinterleaving Pass implementing support for complex numbers in a target-independent manner, deferring to the TargetLowering for the given target to create a target-specific intrinsic.
Differential Revision: https://reviews.llvm.org/D114174
For vector strided instructions, as the RVV spec says:
> When rs2=x0, then an implementation is allowed, but not required, to
> perform fewer memory operations than the number of active elements, and
> may perform different numbers of memory operations across different
> dynamic executions of the same static instruction.
So compiler shouldn't assume that fewer memory operations will be
performed when rs2=x0.
We add a target feature to specify whether u-arch supports optimized
zero-stride vector load. And we do vector splat optimization iff this
feature is supported.
This feature is enabled by default since most designs implement this
optimization.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D137699
We can only return false to abort. If the criteria is met we need
to use continue instead. Returning true stops us from visiting all
nodes and makes the caller think it is safe to remove sext.w.
When we match a pattern from m_GCst, the register type could be different from original op. So we can't replace the original op to vreg direct.
This code create a new constant with original op type then replace the original op.
Fix#58906
Reviewed By: arsenm, aemerson
Differential Revision: https://reviews.llvm.org/D137778
We already surpport the or (xor a, b), (xor c, d) with D136244, while it should
capture more cases than just bcmp according the comment on
https://reviews.llvm.org/D136672, so this patch try to fold continuous
comparison series.
Also add a new callsite in LowerSETCC to address some cases folded And in the
stage of `Optimized type-legalized selection`.
Depends on D136244
Reviewed By: dmgreen, bcl5980
Differential Revision: https://reviews.llvm.org/D137721
We currently will sink either a splat or two extracts to a smull/umull.
There can be cases where we have both one operand as an extract and one
as a splat. This alters the areExtractShuffleVectors method to account
for that case.
Differential Revision: https://reviews.llvm.org/D137726
This reverts commit 8a8983b279dd5e4dceabe1fadbb8980b6adb88f9.
Uncovers existing regalloc issue in Hexagon backend - blocking for Halide
Hexagon users. Reverting to unblock, to be recommitted when underlying issue is resolved.
Reproducer available shortly.
Use right shift [1] as an example
- Before, bfxil is generated (https://godbolt.org/z/EfzWMszPn)
- After, orr with right-shifted operand is generated (added test cases in `CodeGen/AArch64/bitfield-insert.ll`)
[1]
```
define i64 @test_orr_not_bfxil_i64(i64 %0) {
%2 = and i64 %0, 1044480 ; 0xff000
%3 = lshr i64 %2, 12
%4 = or i64 %2, %3
ret i64 %4
}
```
Differential Revision: https://reviews.llvm.org/D137689
In `bfi-not-orr` tests, bfi/bfxil are better since they simplifies away two instructions (extracting bits into destination directly)
In `orr-not-bfi` tests, orr is better since both orr and bfm would simplify away one instruction (the shl node), orr has higher throughput and shorter latency than bfm.
Vector alignment code was grouping all aligned loads together. In some
cases the groups could become quite large causing a lot of spill to be
generated. This will place the loads closer to where they are used,
reducing the register pressure.
In LoongArch, when `CodeModel=Medium`, it just increases the jumping
ability of function calls relative to PC, from 2^28 to 2^32.
Depends on D137393
Reviewed By: SixWeining
Differential Revision: https://reviews.llvm.org/D137394
This patch moves the expansion of the `PseudoCALL` insturction to
`LoongArchPreRAExpandPseudo` pass. This helps to expand into different
instruction sequences according to different CodeModels.
Reviewed By: SixWeining
Differential Revision: https://reviews.llvm.org/D137393
This switches Hexagon intrinsics to use the default attributes
(nosync, nofree, nocallback and willreturn). Especially willreturn
is needed to prevent optimization regressions in the future.
The only intrinsics I've excluded here are the load/store locked
intrinsics, which presumably aren't nosync.
Differential Revision: https://reviews.llvm.org/D137623
Logical operation BIC with DestructiveBinary patterns is temporarily removed as
causes an assert (commit 3c382ed71f15), so try to fix that.
The most significant being that for pseudo instructions that do not have real instructions (including movpfx'd ones) that cover all combinations of register allocation, their expansion will be broken. This is the main reason the zeroing is an experimental feature because it has known bugs.
So we add an extra LSL for movprfx expand BIC_ZPZZ_ZERO A, P, A, A when necessary.
movprfx z0.s, p0/z, z0.s
lsl z0.b, p0/m, z0.b, #0
bic z0.s, p0/m, z0.s, z0.s
Depends on D88595
The CFI directives add noise to the test. Remove them via nounwind fn
attrs. Also remove clobbers.
Reviewed By: void
Differential Revision: https://reviews.llvm.org/D137596
This is based on the example in issue #58883. I'm not sure
if the output currently shows the potential miscompile,
so we may want to adjust the test in a follow-up.
When using `llvm.returnaddress` intrinsic, special handling is required
for the spill of the `RA` register. Otherwise it will cause the verifier
fail in some cases (e.g. pr17377.c of the GCC C Torture Suite).
Specifically:
```
*** Bad machine code: Using an undefined physical register ***
- function: f
- basic block: %bb.0 entry (0xd94d18)
- instruction: ST_D killed $r1, $r22, -40 :: (store (s64) into %stack.2)
- operand 0: killed $r1
```
Reviewed By: SixWeining
Differential Revision: https://reviews.llvm.org/D137387
These hooks ensure that the LoongArch backend can serialize and parse
MIR correctly.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D137482
When streaming mode is enabled, custom-lower arithmetic and logical fixed-width vector ops;
to force generateing code compatible to streaming mode.
Differential Revision: https://reviews.llvm.org/D135324
