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

Phoebe Wang via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Apr 1 21:55:48 PDT 2022


pengfei added a comment.

In D122594#3424091 <https://reviews.llvm.org/D122594#3424091>, @efriedma wrote:

>> So my point is there are only ABI and ABI undefined behaviors, i.e, non ABI implementations. "unstable ABI" is not ABI.
>
> I'm translating this to "The formal ABI has a maximum vector width, and vectors in arguments are restricted to that width. The compiler should report a fatal error if it sees an vector wider than the maximum width."  Am I understanding correctly?  (I can't come up with any other interpretation of your use of "undefined" here.)

No. My understanding on "undefined" is it is allowed (for the sake of optimization) but not guaranteed (sacrificing ABI compatibility).
In this example https://godbolt.org/z/P59Gjjohv, I take the optimization as ABI undefined behavior, because it creates 512bit vector under AVX2 target. But it mostly doesn't matter because both caller and callee are in the same module, so it is allowed.
How about they are in different modules, or one of them is built into library? I believe we don't have real cases for it, because it's mostly error out by front end and middle end won't do such optimizations. But this is the reason why I don't consider them as ABI.

Anyway, I think our controversy on "unstable ABI" and "ABI undefined" won't affect what's the patch trying to fix, if we can make agreement on `abi512_minlegal256` is a bug where arguments should be passed by ZMM register.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122594



More information about the llvm-commits mailing list