If the input vector to INSERT_SUBVECTOR is another INSERT_SUBVECTOR, and this inserted subvector replaces the last insertion, then insert into the common source vector.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
LGTM.
Although I'm somewhat curious about how we even end up with this pattern - I guess for test_mm256_insert_epi64, we really need to have two insert_elements post-legalization, but why do we end up with two insert_subvectors?
lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
13810 ↗ | (On Diff #67385) | Could you make this comment slightly easier to parse? It's probably my fault, but took me a bit too long to understand what you meant. :-) |
Thanks, I've cleaned up the description by using pseudocode instead. I also realised that we need to check the subvector types are the same (e.g. to protect against inserting a 256 following by 128 into a 512).
Any time that we're doing partial insertions (i.e. something that build vector won't handle) we tend to end up with these cases - each insertion has a separate extractsub/insertelt/insertsub pattern - what's curious is that a common extractsub is being used.
If you notice for the lower 128-bit vectors we still have a lot of duplicate blends to bring the lower/upper halves back together again.