Depends on D111135
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/AArch64/AArch64ISelLowering.cpp | ||
---|---|---|
10684 | Is it worth moving this block after the special cases below? I'm just think if there's a time when useSVEForFixedLengthVectorVT accepts 128bit or smaller vectors. | |
10692 | Can you use NewInVec here as UNDEF could create a false dependency that hurts performance. | |
16845–16846 | To me this looks like we're missing a trivial fold within getNode for either BITCAST or whatever DAG.getAnyExtOrTrunc creates? |
- Move fixed type lowering after lowering that ends in no-op
- Don't use undef in lowering
- Remove splice combine change as it is no longer needed
llvm/test/CodeGen/AArch64/sve-fixed-length-extract-subvector.ll | ||
---|---|---|
62–68 | There's a few tests like this that I suspect are not really exercising the extract_subvector logic. Within sve-fixed-length-subvector.ll you'll see I hit a similar issue along with how I worked round it. Essentially for all the tests you want to ensure the call to experimental.vector.extract is within it's own block. |
llvm/test/CodeGen/AArch64/sve-fixed-length-extract-subvector.ll | ||
---|---|---|
62–68 | I'm not actually sure there is anything we can do about this, putting this in it's own block doesn't help. The operand to extract_subvector is not a legal type, hence the legalizer is splitting the operand before we get to try and lower it (which is what we want), which ends up just discarding the extract_subvector. |
llvm/test/CodeGen/AArch64/sve-fixed-length-extract-subvector.ll | ||
---|---|---|
62–68 | I see what you mean. |
Nice improvement!
llvm/lib/Target/AArch64/AArch64ISelLowering.cpp | ||
---|---|---|
10715 | I'm not sure if this really matters because it would probably reuse NewInVec anyway, but strictly this could be UNDEF. |
llvm/lib/Target/AArch64/AArch64ISelLowering.cpp | ||
---|---|---|
10715 | I think it's probably best to leave this as NewInVec, whilst you could probably get away with UNDEF most of the time, you could in theory create false dependencies as Paul noted previously. |
Is it worth moving this block after the special cases below? I'm just think if there's a time when useSVEForFixedLengthVectorVT accepts 128bit or smaller vectors.