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

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added a comment.

In D32530#1475854 <https://reviews.llvm.org/D32530#1475854>, @hsaito wrote:

> 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?


Exactly. Non-constant values can become constant. Constant values can be guarded by vscale-dependent runtime guards (both hand-written and compiler generated). My preference is to leave this not restricted to vscale == 1 values, but rather allow all values that can be supported at runtime, and have it be UB if, at runtime, the relevant index is not available.


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

https://reviews.llvm.org/D32530