[PATCH] D126363: [VPlan, VP] 1/4 Introduce new recipes to support predicated vectorization

Fri May 27 07:51:49 PDT 2022

simoll added a comment.

In D126363#3538646 <https://reviews.llvm.org/D126363#3538646>, @ABataev wrote:

> In D126363#3538612 <https://reviews.llvm.org/D126363#3538612>, @fhahn wrote:
>
>> In D126363#3537438 <https://reviews.llvm.org/D126363#3537438>, @simoll wrote:
>>
>>> In D126363#3537416 <https://reviews.llvm.org/D126363#3537416>, @ABataev wrote:
>>>
>>>> We store the the %evl as the related value for VPValue *EVL using State.set(EVL, %evl, Part) and then get required value using State.get(EVL, Part).
>>>> In this case we can treat EVL similarly to canonical iv, which is not an invariant.
>>>
>>> Ok. If that works then having one global EVL per State defined this way should be fine for us for now.
>>
>> The way VectorTripCount is handled at the moment is a workaround and probably shouldn't act as inspiration. AFAICT we already removed all uses during code-gen that where using `State` to access the vector trip count. If it is needed for code-gen of a recipe, it should be expressed as operand.
>
> Better to treat EVL as CanonicalIV. Yes, I agree that the recipe is better choice here (similar to CaonicalIV) but it requires some extra work because of VPWidenIntOrFpInductionRecipe should depend on EVL. Probably, need to split VPWidenIntOrFpInductionRecipe to a PHI recipe and something like CanonicalIVIncrement, otherwise this dependency prevents it from being vectorized effectively.

Is any of the existing PHI recipes suitable for this? The increment is just an `add`, not sure if that needs its own recipe.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126363/new/

https://reviews.llvm.org/D126363