[PATCH] D112531: [RFC][DataLayout] Allow vector specifications by element size

[Fraser Cormack via Phabricator via llvm-commits]

frasercrmck added a comment.

In D112531#3163628 <https://reviews.llvm.org/D112531#3163628>, @nikic wrote:

> Just to make sure that we don't end up with another incomplete solution: Are there any architectures where alignment could depend on both element size and total size? Are there any where it could depend on element type, i.e. where a vector of i32 and a vector of f32 may have different alignment?

Great question!  I'm not aware of such architectures but that's not to say they don't exist. I'm not sure how best to answer that question, given all the weird and wonderful architectures out there, unless a poll on llvm-dev suffices?

I feel like a spec that can juggle both total size and element size independently in the same DataLayout string is infeasible. Neither choice of how they'd resolve themselves when in conflict is satisfying to me. If `v` takes precedence over `ve` then `ve` is essentially useless (because `v64` and `v128` are legacy-specified by default). But if `ve` takes precedence over `v`  then "`v`-based" architectures become way more verbose. That's why I went with the mutually-exclusive design here.

But narrowing in on your word "and", then maybe if you specified them //together// you can view total size as a specialization which applies on top of element size.

So the first idea that's coming to me right now would be to design a specification that would encode both total size and element size/type. Something like `VX?[eif]N`

- (optional) `X` is the total size (or min size as that's how scalable vectors operate). Defaults to "all vectors".  `X` if specified specializes over all non-specified vector sizes.
- `e` is agnostic element size, `i` is int, `f` is floating-point. `i` or `f` specialize over `e`
- `N` is element size

Something of a superset of this patch. It would allow something like `Ve16` as this patch introduces: all 16-bit-element vectors. `Vf16` could be used on top of that to apply only to all `half` vectors. `V32f16` would apply on top of that to apply to 32-bit (2-element) `half` vectors.

But where does `V64e16` fit into that schema? I think it would probably snuggle in between `Vf16` and `V32f16` but some may argue that `f` is more specific than `e`.

An alternative to total size there would be (min) number of elements, in case that was preferable. And if we decide the size/elts thing is awkward we could still keep the `eif` idea to allow specialization over different element types.

I think `V` and `v` would still continue to be mutually exclusive for the reasons given earlier.

I'm curious to hear your thoughts on this matter.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112531