Now, when llc encounters the case that contains a lot of
extract_vector_elt and a BUILD_VECTOR, it will replace these to
vector_shuffle to decrease the size of code, the actions are done in
createBuildVecShuffle in DAGCombiner.cpp, but now the code cannot handle
the case that the size of source vector reg is more than twice the dest
size.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Now, when llc encounters the case that contains a lot of extract_vector_elt and a BUILD_VECTOR, it will replace these to vector_shuffle to decrease the size of code, the actions are done in createBuildVecShuffle in DAGCombiner.cpp, but now the code cannot handle the case that the size of source vector reg is more than twice the dest size.
Better to limit column width to 80.
Now, when llc encounters the case that contains a lot of
extract_vector_elt and a BUILD_VECTOR, it will replace these to
vector_shuffle to decrease the size of code, the actions are done in
createBuildVecShuffle in DAGCombiner.cpp, but now the code cannot handle
the case that the size of source vector reg is more than twice the dest
size.
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
21203 | This comment looks like it was copy + pasted? |
FWIW, i've recently looked at this method, and, irrespectively of this particular patch,
indeed it misses a quite big number of opportunities, but it also has a very high impact
on the produced DAG, so coming up with the right preconditions is not easy. Alternatively,
we need a significant amount of yak shawing to deal with the new patterns.
It would be great if we can figure out with meticulous patterns. But I think it's still fine to land this as a small step forward.
This comment looks like it was copy + pasted?