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

Wed Feb 12 05:27:43 PST 2020

lkcl added a comment.

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.

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

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

yes, as a separate proposal.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D57504