[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