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

[Sushant Gokhale via llvm-commits]

================
@@ -11019,8 +11039,6 @@ BoUpSLP::getEntryCost(const TreeEntry *E, ArrayRef<Value *> VectorizedVals,
 
   bool NeedToShuffleReuses = !E->ReuseShuffleIndices.empty();
   if (E->isGather()) {
-    if (allConstant(VL))
-      return 0;
----------------
sushgokh wrote:

> I do not see any kind of "complexity" in your constants analysis.

I intend to do that in the next revision of the patch.


I would like to note down the advantages/disadvantages of having constant materialization API consistent with x86/RISCV  i.e. just pass the operands to the TTI API who will call the  constMaterialization API

Advantages:
1. Consistency with other targets
2. Minimal changes in SLP

Disadvantages in the context of this patch:
1. There are multiple scenarios in SLP where constant vectors are used e.g. arithmetic instructions, memory instructions like store, etc. Passing operands for each of the scenario is redundancy and tedious and maybe this needs modification to the TTI APIs as well(getMemoryOpCost for e.g.)
2. When operands are passed to the  TTI APIs, I need to call `getConstantMaterializationCost` from such APIs as is case with RISCV. So, this is redundancy and tedious in the backend as well.
3. The cost for constant vector will be shown to be 0 like
   SLP: Adding cost 0 for bundle Idx: 2, n=2 [i32 11, ..].

   In actual, you would be adding the cost for this constant vector alongwith the instruction. This is confusing and hard to debug.
4. For this specific case, I need to keep track of the vector constants that are already materialized per function so that I avoid double counting the cost at places like loops. Having code for keeping track of already materialized const vectors is easy in SLP rather than keeping in TTI backend and its also the piece of code which is not cost-modelling per se.

Just passing the operands to TTI backend should entail having this piece of code in the backend.

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