In Rust bare-metal targets, there is no environment component in triple name. This patch ignores warnings that look like:
```
warning: triple-implied ABI conflicts with provided target-abi ‘lp64s', using target-abi
```
Reviewed By: SixWeining, xen0n
Differential Revision: https://reviews.llvm.org/D152778
This is the first patch in a series to change how we represent tail agnostic, tail undefined, and tail undisturbed operations. In current code, we tend to use an unsuffixed pseudo for undefined (despite calling it TA most places in code), and the _TU form for both agnostic and undisturbed (via the policy operand).
The key observation behind this patch is that we can represent tail undefined via a pseudo with a passthrough operand if that operand is IMPLICIT_DEF (aka undef). We already have a few instances of this in tree - see vmv.s.x and vslide* - but we can do this more universally. Once complete, we will be able to delete roughly ~1/3 of our vector pseudo classes.
A bit more information on the overall goal can be found in this discourse post: https://discourse.llvm.org/t/riscv-transition-in-vector-pseudo-structure-policy-variants/71295.
This patch doesn't actually remove the legacy unsuffixed pseudo as there's still some path from intrinsic lowering which uses it. (I have not yet located it.) This also means we don't have to modify any of the lookup tables which makes the migration simpler. We can defer deleting the tables and pseudos until one final change once all the instructions have been migrated.
There are a couple of regressions in the tests. At first, these concerned me, but it turns out that all of them are differences in expansion of a single source level instruction. I think we can safely ignore this for the moment. I did explore changing the handling of IMPLICIT_DEF in ScheduleDAG, but that causes an absolutely *massive* test diff with minimal profit. I really don't think it's worth doing.
Differential Revision: https://reviews.llvm.org/D152380
Type legalization may need to promote the result to the same type
as the input. Instead of forming a vp_truncate with the same
source and dest type, don't create any vp_truncate.
Handling in getNode like is done for ISD::TRUNCATE.
This matches gcc. It also lets us fix a bug that the byteselect
predicate was not being evaluated in tablegen. We can't have i8
TImmLeaf in tablegen because i8 isn't a type for any register class.
I've added AutoUpgrade support for the IR intrinsics.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D152627
This patch introduces the reduction intrinsic for floating point minimum
and maximum which has the same semantics (for NaN and signed zero) as
llvm.minimum and llvm.maximum.
Reviewed-By: nikic
Differential Revision: https://reviews.llvm.org/D152370
For example,
smull(trunc(x), extract_high(y))
==>
smull(extract_high(uzp1(undef,x)), extract_high(y))
-> It will be matched to smull2
Differential Revision: https://reviews.llvm.org/D150969
lowerBuildVectorAsBroadcast will not broadcast splat constants in all cases, resulting in a lot of situations where a full width vector load that has failed to fold but is loading splat constant values could use a broadcast load instruction just as cheaply, and save constant pool space.
NOTE: SSE3 targets can use MOVDDUP but not all SSE era CPUs can perform this as cheaply as a vector load, we will need to add scheduler model checks if we want to pursue this.
This is an updated commit of 98061013e01207444cfd3980cde17b5e75764fbe after being reverted at a279a09ab9524d1d74ef29b34618102d4b202e2f
This patch fixes an issue where we were reusing constant pool entries that contained undef elements, despite the additional uses of the 'equivalent constant' requiring some/all of the elements to be zero.
The CanShareConstantPoolEntry helper function uses ConstantFoldCastOperand to bitcast the type mismatching constants to integer representations to allow comparison, but unfortunately this treats undef elements as zero (which they will be written out as in the final asm). This caused an issue where the original constant pool entry contained undef elements, which was shared with a later constant that required the elements to be zero. This then caused a later analysis pass to incorrectly discard these undef elements.
Ideally we need a more thorough analysis/merging of the constant pool entries so the elements are forced to real zero elements, but for now we just prevent reuse of the constant pool entry entirely if the constants don't have matching undef/poison elements.
Fixes#63108
Differential Revision: https://reviews.llvm.org/D152357
Currently, a node and its users are added back to the worklist in reverse topological order after it is combined. This diff changes that order to be topological. This is part of a larger migration to get the DAGCombiner to process nodes in topological order.
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D127115
The division between float constants was done with less
precision. Performing the divide in double and truncating to float
provides the same value as used in the library fast math expansion.
This will map directly to the hardware instruction which does not
handle denormals for f32. This will allow moving the generic intrinsic
to be lowered correctly. Also handles selecting the f16 version, but
there's no reason to use it over the generic intrinsic.
Update the RISC-V Zvk (vector cryptography) extension support from 0.5
to version 0.9.7 (2023-05-31), per
<https://github.com/riscv/riscv-crypto/releases/download/v20230531/riscv-crypto-spec-vector.pdf>
Differences:
- Zvbc is dropped from Zvkn and Zvks, and by extension
from Zvkng and Zvksg;
- new combo extensions Zvknc and Zvksc are introduced,
adding Zvbc to Zvkn and Zvks;
- the experimentatl extensions are tagged as "0.9",
from the earlier "0.5".
Reviewed By: 4vtomat
Differential Revision: https://reviews.llvm.org/D152117
`ctpop(X) eq/ne 1` is checking if X is a non-zero power of 2. Power of
2 check including zero is `(X & (X-1)) eq/ne 0` and unfortunately
there is no good pattern for checking a power of 2 while excluding
zero. So, when lowering `ctpop(X) eq/ne 1`, explicitly check
`IsKnownNeverZero(X)` to maybe be able to optimize out the extra zero
check.
We need this explicitly as DAGCombiner does not re-analyze provable
setcc nodes, and the middle-end never finds it beneficially to broaden
`ctpop(X) eq/ne 1` -> `ctpop(X) ule/ugt 1` (power of 2 including
zero).
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D152675
Consider the following pattern `binOp (select cond, x, c0), c1`.
Where `c0` and `c1` are constants.
We can transform it to `select cond, binOp(x, c1), binOp(c0, c1)`.
If `binOp(c0, c1)` ends up being `0` or `-1` we can turn the select into
a more profitable sequence.
No idea what I was thinking when I suggested vadd.vi.
Reviewed By: reames, frasercrmck, fakepaper56
Differential Revision: https://reviews.llvm.org/D152553
vslideup has a vector overlap constraint that vmv.v.v doesn't.
vmv.v.v is also a simpler instruction so may have better
throughput and/or latency in some CPUs.
This is an alternative to D152298, D152368, and D152496.
Reviewed By: luke, reames
Differential Revision: https://reviews.llvm.org/D152565
There is no need to set a big default stack size for PAL code object indirect
calls. The driver knows the max recursion depth, so it can compute a more
accurate value from the minimum scratch size.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D150609
Other such tests, of which there are many, are to be updated with
separate patches.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D152557
If we have a load/store with an illegal fixed length vector result type that
needs widened, e.g. `x:v6i32 = load p`
Instead of just widening it to: `x:v8i32 = load p`
We can widen it to the equivalent VP operation and set the EVL to the
exact number of elements needed: `x:v8i32 = vp_load a, b, mask=true, evl=6`
Provided that the target supports vp_load/vp_store on the widened type.
Scalable vectors are already widened this way where possible, so this
largely reuses the same logic.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D148713
This commit re-work the methods that dump traces with resource usage to take into account the StartAtCycle value added by https://reviews.llvm.org/D150310.
For each i, the values of the lists StartAtCycle and ReservedCycles is are printed with the interval [StartAtCycle[i], ReservedCycles[i])
```
... | StartAtCycle[i] | ... | ReservedCycles[i] - 1 | ReservedCycles[i] | ...
| xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | |
```
Reviewed By: andreadb
Differential Revision: https://reviews.llvm.org/D150311
Apply my post-commit comment on D81995. The negative name misguided commit
d8a8e5d6240a1db809cd95106910358e69bbf299 (`[clang][cli] Remove marshalling from
Opt{In,Out}FFlag`) to:
* accidentally flip the option to not emit the xray_fn_idx section.
* change -fno-xray-function-index (instead of -fxray-function-index) to emit xray_fn_idx
This patch renames XRayOmitFunctionIndex and makes -fxray-function-index emit
xray_fn_idx, but the default remains -fno-xray-function-index .
XRay instrumentation works for macOS running on Apple Silicon, but
codegen is untested there. I'm going to make changes affecting this
target, get the XRay tests running on AArch64.
Data sections are going to become slightly different on x86_64 soon.
I do want the tests to be specific about symbol names, so instead of
having test check the common step, bifurcate tests a bit and check
the full symbol names.
As for ARM, XRay is not really supported on iOS at the moment, though
ARM is also really used there with modern phones. Nevertheless, codegen
tests exist and the output is going to change a little, make it easier
to write the special case for iOS.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D145291
Something like:
`%r = mul %x, <33, 33, 33, ...>`
Is best lowered as:
`%tmp = %shl x, <5, 5, 5>; %r = add %tmp, %x`
As well, since vectors have non-destructive shifts, we can also do
cases where the multiply constant is `Pow2A +/- Pow2B` for arbitrary A
and B, unlike in the scalar case where the extra `mov` instructions
make it not worth it.
Reviewed By: pengfei
Differential Revision: https://reviews.llvm.org/D150324
This is a quick fix for an assert when the source and dest have
different address spaces. The pointer compare needs to have matching
types, but we can't generically introduce addrspacecast and we don't
know if the address spaces alias.
Since ROLBRd needs an implicit R1 (on AVR) or an implicit R17 (on AVRTiny),
we split ROLBRd to ROLBRdR1 (on AVR) and ROLBRdR17 (on AVRTiny).
Reviewed By: aykevl, Patryk27
Differential Revision: https://reviews.llvm.org/D152248
The commit that added the run says it's to hoist uniform parts of
integer division expansion. That expansion is performed later, so this
didn't do anything in that case. Move this later so the original test
shows the improvement.
This also saves a run of "Canonicalize natural loops". Not sure why
this appears to be still getting a separate loop PM run. Also feels a
bit heavy to run this just for divide. Is there a way to specifically
hoist the divide sequence when it expands?
