[PATCH] D132477: Improve cost model for some 128-bit vector operations that use SVE

[Hassnaa Hamdi via Phabricator via llvm-commits]

hassnaa-arm marked 6 inline comments as done and an inline comment as not done.
hassnaa-arm added inline comments.


================
Comment at: llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp:2055
     InstructionCost Cost = BaseT::getArithmeticInstrCost(
         Opcode, Ty, CostKind, Op1Info, Op2Info);
     if (Ty->isVectorTy()) {
----------------
sdesmalen wrote:
> For the case of using SVE, this probably shouldn't be looking at the original type, but rather the type that is legal for the *operation*.
> 
> There are two separate things going on here:
> 1. The *type* legalization cost, which is the cost of getting a legal type.
> 2. The *operation* legalization cost, which currently assumes a legal type. As your code already points out, operations are only legal on 32- and 64-bit element types.
> 
> The way the code-generator handles this is that for 8 and 16-bit inputs, the *type* legalizer first tries to legalize them to something the code-generator can handle. After that, the code-generator will try to promote it to a type that the *operation* can handle.
> 
> e.g.
> * if the type is <2 x i8> that will be promoted to <2 x i32>. This is all fine, we can use the cost of LT.first (The cost of a DIV for v2i32) and combine it with the legalisation cost for going from v2i8 -> v2i32.
> * if the type is <4 x i16> that is a legal type, but for the DIV operation v4i16 is _not_ legal, so we'll need to consider legalisation for v4i32.
> 
> So for i8 and i16 element types, it should call `getTypeLegalizationCost();` again for the type that we know it will be promoted to. That type is a vector with the same number of lanes, but i32 element types.
> 
I understood the 2 points of legalisation, I agree with you.
But I don't agree about using the function of getTypeLegalizationCost(); to get the cost of *operation* legalisation, because that function is related to *type* legalisation only.

I suggest that, after getting the cost of *type* legalisation,
if the legal type is not 32/64-bit element type, then append the cost for promoting it to the nearest legal element type (32). * the splitting cost.
and then consider the cost of the operation * splitting.



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132477/new/

https://reviews.llvm.org/D132477