[PATCH] D103881: [ValueTypes] Define MVTs for v6i32, v6f32, v7i32, v7f32

Tue Jun 8 20:14:12 PDT 2021

critson added a comment.

In D103881#2805122 <https://reviews.llvm.org/D103881#2805122>, @frasercrmck wrote:

> Awfully brave to add new non-pow2 types; I like it. Unfortunate that we've both filed patches to this same file at the same time (D103884 <https://reviews.llvm.org/D103884>). One of us will have a fun time.

Feel free to commit. I'll rebase this on top of the new state.

In D103881#2805418 <https://reviews.llvm.org/D103881#2805418>, @RKSimon wrote:

> Technically there's precedent with MVT::v3i32 but where does this end? What happens when someone next asks for v8f32 -> v15f32? How tricky would it be for a custom AMDGPU DAG node to encode the vector width instead and it just uses the next pow2 type?

Yes, the precedent is v3i32/v5i32.
I agree its a dangerous slope, but I would be happy if we declared v7 as the hard limit for non-pow2 types.
Declaring a hard limit may also benefit code that has to work with these?

On recent hardware we have features which mean there isn't a need for large contiguous vector types in common cases.
However we have to disable this beyond v5 on some common hardware for stability.
Supporting v6/v7 benefits all our hardware going back many generations (where benefit = reduced register pressure).
I can workaround the lack of v6/v7, but our consensus is that we should just add the MVT types (see D103800 <https://reviews.llvm.org/D103800>).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103881