[llvm] [LV][VPlan] Not adding shuffle cost when store loop invariant value. (PR #109644)

Elvis Wang via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 23 05:43:23 PDT 2024


================
@@ -2253,7 +2253,9 @@ InstructionCost VPWidenMemoryRecipe::computeCost(ElementCount VF,
     Cost += Ctx.TTI.getMemoryOpCost(Ingredient.getOpcode(), Ty, Alignment, AS,
                                     CostKind, OpInfo, &Ingredient);
   }
-  if (!Reverse)
+  // If the store value is a live-in scalar value which is uniform, we don't
+  // need to calculate the reverse cost.
----------------
ElvisWang123 wrote:

This patch cannot fix the instruction cost difference between the VPlan-based and legacy cost model make the VF selection closer.

The cost changed after  the patch
- Scalar cost: 4.
- legacy cost model:
   - Vscale x 1: from 1 (maskedMemoryOpCost) + 6 (shuffle cost) + 3(other cost) to 1 + 3(other cost)
   - vscale x 2: from 2 (MaskedMemoryOpCost) + 11 (shuffle cost) + 3 (other cost) to 2 + 3 (other cost)
- VPlan-based cost model:
   - vscale x 1: from 2 (MemoryOpCost) + 6 (shuffle cost) + 3 (other cost) to 2 + 3 (other cost)
   - vscale x 2: from 3 (MemoryOpCost) + 11 (shuffle cost) + 3 (other cost) to 3 + 3 (other cost)


The root case is caused by the mask for tail folding will transform to EVL after vplan transformations. 
And in the RISCVTTI, the instruction cost from `getMaskedMemoryOpCost()` is difference to instruction cost from `MemoryOpCost()`.
The legacy cost model cannot know if the mask is tail folding and if is valid to transform to EVL. So the legacy cost model will use `getMaskedMemoryOpCost()` to get the instruction cost.
The vplan-based cost model knows it is the EVL recipe and remover the tail mask so it will query the `getMemoryOpCost()`.




https://github.com/llvm/llvm-project/pull/109644


More information about the llvm-commits mailing list