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
Event Timeline
| llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
|---|---|---|
| 586 | This could be applied independently. | |
| llvm/lib/Transforms/Vectorize/VPlan.h | ||
| 1061–1062 | Keep IncomingBlocks in VPWidenPHIRecipe? | |
| 1062 | A [pure virtual] base class inductions[.]and | |
| 1089–1090 | phi/select >> phi | |
| 1099 | it one >> if one | |
| 1104 | "if there is one" - getOperand(1) asserts that there is one... | |
| 1172 | 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 | ||
| 1061–1062 | Sounds good, thanks! Let's keep the base class as lightweight as possible. | |
| 1062 | Adjusted, thanks! | |
| 1104 | Removed. | |
| 1172 | 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 | ||
|---|---|---|
| 1154 | 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 | ||
|---|---|---|
| 1154 | Thanks, I moved it back to VPWidenPHIRecipe in the committed version. | |
This could be applied independently.