[llvm] [VPlan] First step towards VPlan cost modeling. (PR #67934)

Florian Hahn via llvm-commits llvm-commits at lists.llvm.org
Sun Apr 28 05:33:08 PDT 2024


fhahn wrote:

The latest update of the PR includes computing the costs of all VPlans for their associated VFs and then picking the best one. In particular, this also now includes computing costs of replicate regions.

In the initial version, the VPlan-based cost-model first tries to ask the recipe for its cost (via computeCost). If that returns an invalid cost, look up the cost via the legacy cost model. Initially `VPWidenRecipe::computeCost` can compute the costs for almost all opcodes (except UDiv, SDiv, URem, SRem and recipes in reduction chains) which which have more complex logic in the legacy cost-model.

I tested the latest version on a range of configurations and code-bases (llvm-test-suite + SPEC2017 + Clang bootstrap on AArch64 with and without SVE, with and without `-prefer-predicate-over-epilogue=predicate-else-scalar-epilogue` and X86 with AVX512) and both legacy and VPlan cost-models agree on the selected VF in all cases. (there are 2 cases where the legacy cost model computes the cost inaccurately, which I'll submit fixes for shortly)

I added a number of test cases separately for loops where they disagreed before. There may be cases where the assertion gets triggered still due to missing coverage. It may also trigger in hand-written test cases that contain dead code, which VPlan transform will remove before computing the test (at the moment causing `Transforms/LoopVectorize/ARM/tail-folding-counting-down.ll` to fail), so we may want to either remove the assert or guard it by an option.

Another thing to note is that during cast-simplifications, we preserve the underlying instruction, so we can still use the legacy cost-model for the casts, as otherwise we would also need to implement costing for casts directly. This is an area where there may be some differences between legacy and VPlan-based cost-model, due to the latter having more accurate information.

Going forward I think we should gradually move cost computation to the VPlan-based model and allow divergence as needed when the VPlan-based model more accurately estimates cost.

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


More information about the llvm-commits mailing list