[PATCH] D131015: [LV] Track all IR blocks corresponding to VPBasicBlock

Ayal Zaks via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 7 13:47:33 PDT 2022


Ayal added inline comments.


================
Comment at: llvm/lib/Transforms/Vectorize/VPlan.cpp:373
 
-  State->CFG.VPBB2IRBB[this] = NewBB;
+  State->CFG.VPBB2IRBB[this].push_back(NewBB);
   State->CFG.PrevVPBB = this;
----------------
Hmm, VPBasicBlock::execute() is called once per VPBB when generating IR, so how could VPBB2IRBB record multiple/overwriting NewBB's here per same `this`? If there are such cases, perhaps its better to simplify them and retain a single IRBB per VPBB, adding an assert that no overwriting takes place. VPBB's contain only recipes and are free of control-flow - which is modeled using multiple VPBB's and VPRegions - so should fill a single IRBB.

A related issue are A-B-C cases above that try to reuse the same IRBB for pairs of back-to-back VPBB's (which may best be avoided for clarity and left to subsequent simplifyCFG to fold instead), but these are multiple VPBB's filling one IRBB, rather than the converse.

Another related issue is the correspondence between original IRBB's and VPBB's during VPlan construction rather than execution. There multiple replicate-and-predicate recipes that stem from the same IRBB are each assigned separate VPBB's (of a replicating region), as can be seen by trying to assign each such VPBB a unique name associated with its original IRBB (`VPBBsForBB`). Again yielding multiple VPBB's per one IRBB.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131015/new/

https://reviews.llvm.org/D131015



More information about the llvm-commits mailing list