Add first VPlan-based recipe simplification to fold (MUL A, 1) -> A.
Among other things, this enables additional simplifications after
applying versioned strides, as follow up to D147783.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
LGTM, adding various nits and thoughts.
llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp | ||
---|---|---|
803 | nit: could become a method of VPValue? | |
811 | Also handle VPInstruction via its getOpcode()? nit: could become a method of VPRecipeBase? | |
819 | nit: would "constantFold" be more accurate than the general "simplify"? Comment that collecting R's folded into their operands is left for subsequent DCE. May be worth indicating if any change was made, at some point - relevant for VPlan2VPlan passes in general. May be worth testing that Mul 1, 1 gets optimized into a live-in. | |
832 | nit: would "constantFold" be more accurate than the general "simplify"? |
llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp | ||
---|---|---|
803 | I am planning to follow up by adding/extending PatternMatcher.h support for VPlan, which seems like an appropriate place for it to live | |
811 | Updated to also handle VPInstruction, thanks! I am planning to follow up by adding/extending PatternMatcher.h support for VPlan, which seems like an appropriate place for it to live, in particular because there are various recipes that cannot be mapped to an opcode at the moment or it is at least not entirely clear to which opcode they should be matched, e.g. interleave or canonical IV recipes. | |
819 | I think constantFold would be too narrow, as other 'instcombine' style simplifications would be a good fit here as needed. |
nit: could become a method of VPValue?