Specifically, this allow us to rely on the lane zero'ing behaviour of
SVE reduce instructions.
Co-authored-by: Paul Walker <paul.walker@arm.com>
Paths
| Differential D101369
[AArch64][SVE] Fold insert(zero, extract(X, 0), 0) -> X, when X is known to zero lanes 1-N ClosedPublic Authored by bsmith on Apr 27 2021, 8:28 AM.
Details Summary Specifically, this allow us to rely on the lane zero'ing behaviour of Co-authored-by: Paul Walker <paul.walker@arm.com>
Diff Detail
Event TimelineComment Actions LGTM, modulo nit. Test suggestion: what about testing an insert into a non zeroinitializer vector?
This revision is now accepted and ready to land.Apr 27 2021, 8:58 AM
Comment Actions The documentation for the nodes you are using the implicit zeroing of say "// Only the lower result lane is defined." Should that be changed to explain that all non-zero lanes are zero?
bsmith marked 4 inline comments as done. Comment Actions
This revision was landed with ongoing or failed builds.May 4 2021, 7:05 AM Closed by commit rG9f37980d45c7: [AArch64][SVE] Fold insert(zero, extract(X, 0), 0) -> X, when X is known to… (authored by bsmith). · Explain Why This revision was automatically updated to reflect the committed changes.
Revision Contents
Diff 340856 llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
llvm/test/CodeGen/AArch64/sve-implicit-zero-filling.ll
|
Sorry to chip in here as I realise I'm not a reviewer. :) However, the ANDV instruction has a scalar SIMD&FP register for it's result, so it doesn't feel right to say all the other lanes >0 in the equivalent SVE register are zero. I'd have expected something more like isOnlyFirstLaneDefined? I understand you named this function because currently it's only called from performInsertVectorEltCombine where the insert vector is a null splat, but other users may call it elsewhere in future and it feels a bit dangerous to give it a misleading name that's all.