[PATCH] D122594: [ArgPromotion] Update min-legal-vector-width when do promotion

[Craig Topper via Phabricator via llvm-commits]

craig.topper added a comment.

In D122594#3419310 <https://reviews.llvm.org/D122594#3419310>, @pengfei wrote:

> In D122594#3417331 <https://reviews.llvm.org/D122594#3417331>, @efriedma wrote:
>
>> Do we have documentation for min-legal-vector-width anywhere in-tree?
>
> Unfortunately, I don't think we have documentation for it. @craig.topper, right?

I guess not.

>> I guess the hierarchy currently works like the following:
>>
>> - CPU attributes control what register width codegen for a function can assume is available.
>> - prefer-vector-width reduces the max width of registers codegen actually uses, for the sake of avoiding vector ops that force the CPU to downclock etc.
>> - min-legal-vector-width makes codegen ignore prefer-vector-width, so intrinsics etc. work transparently.
>
> I'd take "min-legal-vector-width" as a awful supplementary due to we implemented "prefer-vector-width" in an odd way. I talked with GCC folks, who told me GCC implemented it through providing different cost model. I wonder why didn't we doing the same way at the beginning. I can see it's more concise and won't introduce any ABI problems.

The vectorizer even with AVX2 frequently generates vectors with more than 256 bits and relies on the backend type legalizer to split them. In order to get similar codegen with prefer-vector-width=256 we had to create the same type legalizer behavior without taking away the vectorizer's freedom to generate oversized vectors. The min-legal-vector-width was trying to capture where the vectors came from to distinquish vectorizer code from user code.

>> Then for calls:
>>
>> - If a call a function with a very wide vector argument, it's split according to prefer-vector-width/min-legal-vector-width of the caller.
>> - If a function definition has a very wide vector argument, it's split according to prefer-vector-width/min-legal-vector-width on that definition.
>
> That's not correct. Splitting is not allowed according to ABI. Splitting is just the mechanism how backend handles illegal vectors. So one of the problem prefer-vector-width/min-legal-vector-width is solviong is to avoid the backend takes ABI legal vactors as illegal and split them.
>
>> Therefore, if a function has a vector argument, the caller and the callee must have the same values of min-legal-vector-width/prefer-vector-width...?
>
> It's not correct either. Caller and callee can have different values of min-legal-vector-width/prefer-vector-width as long as all the arguments are legal to their min-legal-vector-width. For example, caller can have min-legal-vector-width=512 and callee can have min-legal-vector-width=0 if there's no vector arguments passing. prefer-vector-width should not affect the arguments, because we have set min-legal-vector-width to the correct value. But if we didn't, the different prefer-vector-width might result in ABI mismatch.
>
>> I'm tempted to say we should have a separate abi-vector-width; this controls how vector arguments to functions are split, and no other function attributes have an effect.  If we have that, we can ensure the ABI is consistent without worrying about prefer-vector-width/min-legal-vector-width/target features.
>
> I don't think we need a abi-vector-width. For one thing, abi-vector-width can be inferred by target. For another, we never split arguments according to ABI.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122594