For example, a build_vector of i64 bitcasted from v2i32 can be turned into a concat_vectors of the v2i32 vectors with a bitcast to a vXi64 type.
Details
Diff Detail
Event Timeline
Can you upload again with context?
Do you know if we can declare victory over PR34716 after this?
https://bugs.llvm.org/show_bug.cgi?id=34716
lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
14952 | Also, should this be limited to before LegalOperations in case a backend is trying to do this in reverse? |
lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
14950–14951 | Add a formula in the comment to describe the transform? | |
14952 | That sounds right. I think this is wrong frequently, but nobody notices because it's not exposed in regression tests for in-tree targets. Another option - if we do want to run this after legalization - would be to check if the CONCAT is legal or custom before creating it? | |
14953 | Might want to use 'peekThroughBitcast' here...although that reminds me that I still need to figure out if we can remove the loop in there yet. |
lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
14953 | I thought about that, but I would have to still verify that at least one bitcast had existed. My assumption is that if there were multiple bitcasts, they would be combined and cause this user to get re-evaluated right? |
lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
14953 | You can't have a build vector of vectors, so I think there has to be a bitcast in order for the isVector() to match. Multiple bitcasts should get folded, but last time I removed the loop from 'peekThroughBitcasts', I saw regressions. I guess this a consequence of not running to fix-point...you're never quite sure what will get combined. :) Either way is ok here I think. |
Add a formula in the comment to describe the transform?
build_vector [ bitcast (Splat0), bitcast (Splat0), ...] --> bitcast (concat_vectors Splat0)