fhahn wrote: > The VPUniformPerUFRecipe of the current patch deals only with casts, so best > name it as such, at-least for now, and define it comparable to > VPWidenCastRecipe. Perhaps VPScalarCastRecipe would work - it effectively > serves Invariant values placed outside the loop that are Uniform across all > trip-count iterations, not only across the loop's VF and/or UF. Down the > road, it should presumably be possible to query whether its VPValue operand > is scalar or vector along with its uniformity across VF and/or UF or the > entire Trip Count, and use that for cost and code-generation, or for > asserting the case of distinct recipes.
Thanks, for now I updated the naming to reflect the cast-only case. Codegen is only implemented for the cases where only the first lane is used (as per `isOnlyFirstLaneUsed` check). > How to refactor VPReplicateRecipe, relieving it of relying on an underlying > IR instruction, and dealing with uniform cases, deserves further thoughts. > Renaming may be adequate when recipe(s) generate scalar instruction(s) in > general, rather than "replicate" an existing underlying Instruction. I.e., in > contrast to VPReplicateCastRecipe. Sounds good! > One aspect of VPWidenCastRecipe is its destination type. A vector type, > currently set during ::execute, can be set as soon as VF is known. I.e., when > VPlan's range of VF's holds a single value - either initially or eventually > during optimizeForVFAndUF. Yes, that may be another option down the line. https://github.com/llvm/llvm-project/pull/78113 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
