Not all header phis widen the phi, e.g. like the new
VPCanonicalIVPHIRecipe in D113223. To let those recipes also inherit
from a phi-like base class, add a more generic VPHeaderPHIRecipe
abstract base class.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
60 ms | x64 debian > LLVM.Bindings/Go::go.test |
Event Timeline
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
586 | This could be applied independently. | |
llvm/lib/Transforms/Vectorize/VPlan.h | ||
1063 | A [pure virtual] base class inductions[.]and | |
1069 | Keep IncomingBlocks in VPWidenPHIRecipe? | |
1094 | phi/select >> phi | |
1103 | it one >> if one | |
1108 | "if there is one" - getOperand(1) asserts that there is one... | |
1139 | Indep, of this patch, but why not have one constructor: VPWidenPHIRecipe(PHINode *Phi, VPValue *Start = nullptr) : VPHeaderPHIRecipe(VPVWidenPHISC, VPWidenPHISC, Phi, Start) {} |
Address latest comments, thanks!
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
586 | I'll push it as a separate commit | |
llvm/lib/Transforms/Vectorize/VPlan.h | ||
1063 | Adjusted, thanks! | |
1069 | Sounds good, thanks! Let's keep the base class as lightweight as possible. | |
1108 | Removed. | |
1139 | Good point! I rather remove the (single?) users of the constructor without start value as follow-up |
Looks good to me, with a last nit.
llvm/lib/Transforms/Vectorize/VPlan.h | ||
---|---|---|
1121 | Leave getIncomingValue() in VPWidenPHIRecipe, for VPlan native? It seems to complement getIncomingBlock() and addIncoming(), and is synonymous with getOperand(),,, |
llvm/lib/Transforms/Vectorize/VPlan.h | ||
---|---|---|
1121 | Thanks, I moved it back to VPWidenPHIRecipe in the committed version. |
This could be applied independently.