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

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

> 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.

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.

> 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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122594