Split VPlanTransforms::addExplicitVectorLength into variable step transformation and header mask optimisation

[lukel97]

The transform that converts recipes into EVL recipes currently does two things:

1. It converts the vector loop region from having a fixed step of VF, to a variable step of EVL
2. It converts recipes which use the header mask to VP intrinsic based recipes

(1) changes the behaviour of the loop, whereas (2) is an optimisation to remove the need to compute a mask.

In theory we can just run (1) and still have a correct loop, because the header masks will make sure we don't execute trapping lanes etc, and we could move the (2) to VPlanTransforms::optimize.
Unfortunately we can't do this today because we somewhat conflate the two.

The main example that comes to mind is when we replace all uses of VF with EVL. When we replace it for VPWidenIntOrFpInductionRecipe/VPWidenPointerInductionRecipe/VPScalarIVSteps, this is for (1).

However, we also replace the VF operand in VPVectorEndPointerRecipe. This leaves the plan in an incorrect state until we convert VPWidenLoadRecipe to VPWidenLoadEVLRecipe, because the address is shifted in a way that requires the header mask to be removed.

A plan of action to untangle this could be:

• Convert the header masks first to the EVL equivalent icmp ult step-vector, EVL before doing any header mask optimization. [LV][EVL] Simplify EVL recipe transformation by using a single EVL mask. nfc #152479 fixes this
• Adjust the VPVectorEndPointerRecipe VF operand alongside each load/store instead of globally
• Currently we transform all widened load/store/reduction recipes to EVL recipes. Change this to only transform them if they match the header mask
• Move the EVL recipe transformations into VPTransforms::optimize. Requires moving transformRecipestoEVLRecipes into tryToBuildVPlanWithVPRecipes

[llvmbot]

@llvm/issue-subscribers-backend-risc-v

Author: Luke Lau (lukel97)

The transform that converts recipes into EVL recipes currently does two things:

1. It converts the vector loop region from having a fixed step of VF, to a variable step of EVL
2. It converts recipes which use the header mask to VP intrinsic based recipes

(1) changes the behaviour of the loop, whereas (2) is an optimisation to remove the need to compute a mask.

In theory we can just run (1) and still have a correct loop, because the header masks will make sure we don't execute trapping lanes etc, and we could move the (2) to VPlanTransforms::optimize.
Unfortunately we can't do this today because we somewhat conflate the two.

The main example that comes to mind is when we replace all uses of VF with EVL. When we replace it for VPWidenIntOrFpInductionRecipe/VPWidenPointerInductionRecipe/VPScalarIVSteps, this is for (1).

However, we also replace the VF operand in VPVectorEndPointerRecipe. This leaves the plan in an incorrect state until we convert VPWidenLoadRecipe to VPWidenLoadEVLRecipe, because the address is shifted in a way that requires the header mask to be removed.

A plan of action to untangle this could be:

• Adjust the VPVectorEndPointerRecipe VF operand alongside each load/store instead of globally
• Currently we transform all widened load/store/reduction recipes to EVL recipes. Change this to only transform them if they match the header mask
• Move the EVL recipe transformations into VPTransforms::optimize. Requires moving transformRecipestoEVLRecipes into tryToBuildVPlanWithVPRecipes

[lukel97]

With #146525, I think the current transforms for widened loads and stores in optimizeMaskToEVL will need to be rewritten in terms of pattern matching, because for reverses we will need to match from the start of the reverse. E.g. we might have the following transforms for loads:

   (load ptr, header-mask)
   ->
   (vp.load ptr, all-true, evl)
   
   (reverse (load (end-ptr p, vf), (reverse header-mask)))
   ->
   (vp.reverse (vp.load (end-ptr p, evl), all-true, evl), evl)
   
   (reverse (load (end-ptr p, vf), (reverse (and header-mask, other-mask))))
   ->
   (vp.load (end-ptr p, evl), (vp.reverse other-mask evl), evl)

cc) @arcbbb

[Mel-Chen]

I’m working on something related to your last point. https://github.com/Mel-Chen/llvm-project/commits/evl-move-to-tryToBuildVPlanWithVPRecipes/
Created an issue to avoid duplicated work. #153144