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

[Phoebe Wang via Phabricator via llvm-commits]

pengfei added a comment.

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

>> 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 think given the penalty for even a single zmm instruction, the original authors wanted to make sure it was impossible for SelectionDAG to generate zmm registers by accident.  So instead of just trying to avoid them in IR, prefer-vector-width actually marks the types illegal in SelectionDAG.  Given that, min-legal-vector-width exists to ensure that code that explicitly uses zmm intrinsics actually uses zmm registers.

But it's too strict. We are not "force" but "prefer" it :)

> In theory, the backend could try to deduce min-legal-vector-width, but accurately scanning is a little tricky, and it might lead to weird results like "user uses zmm intrinsic, but the backend decides to split it into multiple ymm instructions".
>
> Not sure I really agree with this design, but that's the motivation.

Thanks! I see the motivation. I think it's still fine if we don't modify arguments in middle end. But the problem this patch tries to fix as well as some down stream scenarios show the defect of the design and I want to see if we can find a better way.

>> For another, we never split arguments according to ABI.
>
> To clarify about ABI here: we don't only care about the formal x86 ABI specification here, which only specifies rules for __m128/__m256/etc. vector types.  We also care about doing something sane for languages/frontends that have language-level support for arbitrary vector types.  We don't necessarily have to "split" here, but we have to do something, and splitting is the natural default given the way SelectionDAG works.

Yeah, I particularly meant to X86 psABI <https://gitlab.com/x86-psABIs> when I mentioned ABI somewhere. I think it's interesting to distinguish ABI and LLVM implementations. An ABI has its implementation, but not all implementations are specified by ABI documents.

For example, we have arbitrary scalar and vector types in IR, it's true we always be able to lower them. However, some of them are not ABI supported type, e.g, <8 x i1>, i192.

The important difference between ABI implementation and non ABI implementation is we are free to change the latter but have to always keep it the same for the former. We are continually changing the non ABI implementations once we added new supported type into ABI. We have done for 512 bit vector, we are doing for half type, we will going to do for i192 etc.

In a word, we don't have ABI for arbitrary types. We should call it ABI only for types defined on ABI documents.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122594