[PATCH] D32530: [SVE][IR] Scalable Vector IR Type

Hideki Saito via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 23 10:39:54 PDT 2019


hsaito added a comment.

In D32530#1475356 <https://reviews.llvm.org/D32530#1475356>, @huntergr wrote:

> In D32530#1474555 <https://reviews.llvm.org/D32530#1474555>, @greened wrote:
>
> > In D32530#1470784 <https://reviews.llvm.org/D32530#1470784>, @hfinkel wrote:
> >
> > > In D32530#1470773 <https://reviews.llvm.org/D32530#1470773>, @greened wrote:
> > >
> > > >
> > >
> >
> >
> >
> >
> > >> I am not sure how it could be anything but `n`.  If you don't know how long the vector is, you can't correctly generate an index beyond `n`.
> > > 
> > > But you know at runtime... there has to be a way to determine, at runtime, vscale. And the index doesn't need to be a constant. I'm not sure that we need to restrict non-constant n to only values valid for vscale == 1.
> >
> > Good point.  100% agree.  I was only considering the constant case.
>
>
> Ok, so do we have agreement that constant literal indices should be limited to `0..n-1` for now, but non-constant indices can potentially exceed `n` so that expressions featuring `vscale` can be used?


I want to say yes here, but that leaves a bit of oddness. It's true that nobody can really police on true variable values. However, some variable values can become constant through optimization.
What's the behavior when >=n constant is exposed?


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

https://reviews.llvm.org/D32530





More information about the llvm-commits mailing list