[PATCH] D69891: [VP,Integer,#1] Vector-predicated integer intrinsics

Simon Moll via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 13 02:23:22 PST 2020


simoll added a comment.

In D69891#1872419 <https://reviews.llvm.org/D69891#1872419>, @rkruppe wrote:

> In D69891#1871485 <https://reviews.llvm.org/D69891#1871485>, @simoll wrote:
>
> > Ok. This is a summary of the requested changes and i'd like to get your go ahead before "committing" them to the patch:
> >
> > 1. **Define what 'W' is** (that is the vector length that `%evl` is compared against) - for static vector types this would be the number of elements of the vector, for scalable types `W == MVL` and the target is responsible for defining `MVL`.
>
>
> I object. The only sensible definition for the upper bound on %evl is the number of elements in the vector type in question (because %evl counts vector elements). We already have a concept of "number of elements in a vector type" that generalizes across all vector types (fixed-width and scalable), and it is quite target-independent: `<vscale x $N x $elemtype >` (where `$N` is a constant) has `vscale * $N` elements. The only target-dependent part is in the positive integer `vscale`, and its behavior is quite restricted. All of this is already stated in the LangRef (in the section on vector types), and there is no reason for VP intrinsics to repeat it, let alone deviate from it by e.g. introducing new terminology (MVL) or making provisions for more target-dependent behavior than actually exists. The VP instructions should just define their behavior in terms of the number of elements in the vector.


+1 
I was complicating things. `MVL == number of vector elements` and the whole discussion about what `MVL` is and how it is read/set really is part of the scalable type/vscale discussion.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69891





More information about the llvm-commits mailing list