This is an archive of the discontinued LLVM Phabricator instance.

[DAG] visitINSERT_VECTOR_ELT - attempt to reconstruct BUILD_VECTOR before other fold interfere
ClosedPublic

Authored by RKSimon on Jun 12 2022, 4:57 AM.

Details

Summary

Another issue unearthed by D127115

We take a long time to canonicalize an insert_vector_elt chain before being able to convert it into a build_vector - even if they are already in ascending insertion order, we fold the nodes one at a time in to the build_vector 'seed', leaving plenty of time for other folds to alter it (in particular recognising when they come from extract_vector_elt resulting in a shuffle_vector that is much harder to fold with).

D127115 makes this particularly difficult as we're almost guaranteed to have the lost the sequence before all possible insertions have been made.

This patch proposes to begin at the last insertion and attempt to collect all the (oneuse) insertions right away and create the build_vector before its too late.

Diff Detail

Event Timeline

RKSimon created this revision.Jun 12 2022, 4:57 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 12 2022, 4:57 AM
RKSimon requested review of this revision.Jun 12 2022, 4:57 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 12 2022, 4:57 AM
RKSimon updated this revision to Diff 436209.Jun 12 2022, 4:58 AM

fix typo in comment

RKSimon added inline comments.Jun 12 2022, 5:06 AM
llvm/test/CodeGen/AArch64/sve-fixed-length-insert-vector-elt.ll
232

Minor aarch64 optimization - insertelement v1f64 folds to a move but buildvector doesn't?

deadalnix accepted this revision.Jun 12 2022, 8:43 AM

The test for which this triggers seems overly restrictive, but this is good.

llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
19433

That seems overly restrictive:

  • The remaining elements could be undef - this is a relatively common occurrence, as far as i can tell.
  • The element could be inserted in pretty much any order (unless there is some canonicalization?)
19444

this assumes proper order, do we make sure this is cannonical in some way?

This revision is now accepted and ready to land.Jun 12 2022, 8:43 AM
RKSimon added inline comments.Jun 12 2022, 9:06 AM
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
19376

@deadalnix We canonicalize to ascending order here

deadalnix added inline comments.Jun 12 2022, 3:39 PM
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
19376

I see. Great.

dmgreen added inline comments.Jun 13 2022, 12:09 AM
llvm/test/CodeGen/AArch64/sve-fixed-length-insert-vector-elt.ll
232

Should a single element buildvector be canonicalized to a scalar_to_reg?

RKSimon added inline comments.Jun 13 2022, 1:01 AM
llvm/test/CodeGen/AArch64/sve-fixed-length-insert-vector-elt.ll
232

I tested with folding to scalar_to_vector and this test had the same problem.

foad added a subscriber: foad.Jun 13 2022, 1:54 AM

Personally I think IR should have a buildvector instruction instead of an insertelement instruction. :)

Personally I think IR should have a buildvector instruction instead of an insertelement instruction. :)

The proliferation of option to build a vector are probably playing against us, indeed. build_vector, insert_element, vector_shuffle, etc...

We are bound to miss patterns.

If you rebase this, you'll notice there is a big win in shuffle-extract-subvector.ll

This revision was landed with ongoing or failed builds.Jun 13 2022, 3:49 AM
This revision was automatically updated to reflect the committed changes.