This patch supports to identify build_vector of the VID sequence with just one inconsistent element, and will lower it to vid and insert_vector_elt.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | ||
---|---|---|
1914 | This is algorithmically slow. You can achieve the same effect with a direct change to the matching code which allows it to fuzzy match exactly one element. Doing so is non trivial, but once you find the first three non-undefs in the sequence it should be easy to distinguish. | |
llvm/test/CodeGen/RISCV/rvv/fixed-vectors-fp-shuffles.ll | ||
142 | Its not clear to me that a six instruction sequence is worthwhile to remove a constant pool entry. Can you make an argument as to why this change is worthwhile? |
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | ||
---|---|---|
1914 | I agree. It seems unfortunate to pessimise almost all BUILD_VECTOR compile times just for this case. Does this really show up in real-world code often enough to warrant this optimization? Do we really want to match a v256 build vector where only element 148 is out of sequence, for example? |
This is algorithmically slow.
You can achieve the same effect with a direct change to the matching code which allows it to fuzzy match exactly one element.
Doing so is non trivial, but once you find the first three non-undefs in the sequence it should be easy to distinguish.