[llvm] [AArch64][CostModel] Consider the cost of const vector (PR #117539)

David Green via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 6 01:06:18 PST 2024


davemgreen wrote:

> Can you provide example where the scalar can be free ?

Anything that can include the immediate in the instruction (relatively common for scalar integers, eg addri,  relatively uncommon for vectors but can happen for const shift amounts or sve adds, for example). Also any constant that is materialized once but used multiple times, especially if it is used in a loop. It is hopefully relative simple to detect that we are in the loop case, if we can communicate that to the cost functions.

> Can you provide example ?

Mostly doubles, if they cannot be materialized more nicely: https://godbolt.org/z/aYsMfojfn

> ld1 instruction is already having cost=4 although we split it into load+insert. For this specific case, we dont have such thing and hence, the entire cost has been attributed to ldr. In fact, if the cost is reduced to 3, we dont see the gains with leela benchmark.

ld1 (lane insert) are more expensive (they are split into two mops), but these are just constant-pool loads. Can you explain more details about what the gain is caused by, and what code it comes from? Is there some other place that the cost is inaccurate in it? A load that hits cache should be relatively cheap. One that misses cache is more expensive, especially in terms of latency.

> Having something like [this](https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/AArch64/AArch64Subtarget.h#L61) is what you are suggesting?

No - I would hope this doesn't need to be sub-target specific. I was hoping for a consistent way of modelling constants, whether that is through a method like getIntImmCost, through the operands of getArithmeticInstrCost or via something like getConstantMaterializationCost directly. I'm not sure what the best approach is.

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


More information about the llvm-commits mailing list