[PATCH] D57504: RFC: Prototype & Roadmap for vector predication in LLVM

[Simon Moll via Phabricator via llvm-commits]

simoll added a comment.

In D57504#1871991 <https://reviews.llvm.org/D57504#1871991>, @lkcl wrote:

> In D57504#1871521 <https://reviews.llvm.org/D57504#1871521>, @simoll wrote:
>
> > In D57504#1862968 <https://reviews.llvm.org/D57504#1862968>, @lkcl wrote:
> >
> > > i have a suggestion.  for SimpleV we.definitely need to have an explicit way to specify MVL. this because it is literally specifying precisely how many scalar registers are to be allocated for a vector op.
> >
> >
> > Would it work for you if we leave the definition of `MVL` for scalable types to the targets?
>
>
> mmm... honestly?  probably not.  however we can get away with either inline assembler (for a very limited subset of requirements) or just going "y'know what, let's just set MVL hard-coded to default to 4 or 8 for all loops", for now, as best matched to the (planned) maximum internal register read/write ports for our first chip.


I think i wasn't clear: what i meant to say is that we will not decide how MVL is defined/queried/set in the scope of this RFC... potentially leading to the situation that every target comes with its own set of target intrinsics to do so.

> 
> 
>> This would allow you (and ARM MVE/SVE , RISC-V V) to have their own mechanism for setting/querying `MVL`.
> 
> and x86-for-hinting-the-SIMD-length.

For x86 with scalable types, yes. For "classic" SIMD types `MVL == W` of `<W x type>`

> <snip>  [for anyone who may be under the impression that RVV does not need the concept of MVL: see the sub-extension which fits the vector regfile onto the scalar (FP) regfile.  if the FP regfile is to be used and useful at the same time, then tere needs to be a way to explicity define how much of the FP regfile is to be allocated (to* RVV, and that in turn means being able to define the number of "lanes" to actually be used... which is, funnily enough, exactly what *setting* MVL.  N(Lanes) == MVL.  MVL == N(Lanes) ].
> 
>> Besides, i think that defining `MVL` is out of the scope of this RFC given the diversity of scalable vector ISAs right now..
> 
> this is cool and exciting.

Yep, and we wouldn't get near the level of support for this RFC otherwise.

> 
> 
>> again a point we could revisit should all scalable vector ISAs someday agree on one way to define `MVL`.
> 
> yes, as a separate proposal.

+1


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D57504