[llvm] [VPlan] Add VPIRBasicBlock, use to model pre-preheader. (PR #93398)
via llvm-commits
llvm-commits at lists.llvm.org
Wed May 29 13:17:06 PDT 2024
================
@@ -2948,12 +2952,48 @@ class VPBasicBlock : public VPBlockBase {
return NewBlock;
}
+protected:
+ /// Execute the recipes in the IR basic block \p BB.
+ void executeRecipes(VPTransformState *State, BasicBlock *BB);
+
private:
/// Create an IR BasicBlock to hold the output instructions generated by this
/// VPBasicBlock, and return it. Update the CFGState accordingly.
BasicBlock *createEmptyBasicBlock(VPTransformState::CFGState &CFG);
};
+/// A special type of VPBasicBlock that wraps an existing IR basic block.
+/// Recipes of the block get added before the first non-phi instruction in the
+/// wrapped block.
+class VPIRBasicBlock : public VPBasicBlock {
+ BasicBlock *IRBB;
+
+public:
+ VPIRBasicBlock(BasicBlock *IRBB)
+ : VPBasicBlock(VPIRBasicBlockSC,
+ (Twine("ir-bb<") + IRBB->getName() + Twine(">")).str()),
+ IRBB(IRBB) {}
+
+ ~VPIRBasicBlock() override {}
+
+ static inline bool classof(const VPBlockBase *V) {
+ return V->getVPBlockID() == VPBlockBase::VPIRBasicBlockSC;
+ }
+
+ /// The method which generates the output IR instructions that correspond to
+ /// this VPBasicBlock, thereby "executing" the VPlan.
+ void execute(VPTransformState *State) override;
+
+ VPIRBasicBlock *clone() override {
+ auto *NewBlock = new VPIRBasicBlock(IRBB);
----------------
ayalz wrote:
This cloning produces multiple VPBB's holding the same IRBB, all destined to inject instructions into it following its last phi. Can we verify that the order in which these VPBB's will execute corresponds to related dependences - if any, perhaps by asserting that in any given VPlan all VPIRBasicBlocks hold distinct IRBB's? And/or document this concern.
https://github.com/llvm/llvm-project/pull/93398
More information about the llvm-commits
mailing list