[llvm-dev] [RFC][SVE] Supporting SIMD instruction sets with variable vector lengths

Renato Golin via llvm-dev llvm-dev at lists.llvm.org
Mon Oct 15 05:05:30 PDT 2018


On Mon, 15 Oct 2018 at 12:04, Graham Hunter <Graham.Hunter at arm.com> wrote:
> > Another solution would be to make it return ScalableSize.Unscaled. At
> > least in a transition period.
>
> True, though there are places in the code that expect a size of 0 to mean
> "this is a pointer", so using scalable vectors with that could lead to
> incorrect code being generated instead of an obvious ICE.

I see.


> This work is biased towards 'true' being valid if and only if the condition
> holds for all possible values of vscale. This does mean that returning a
> 'false' in some cases may be incorrect, since the result could be true for
> some (but not all) vscale values.

I wonder is there's any case where returning a wrong false would be
problematic.

I can't think of anything, so I agree with your approach. :)


> Do you think that implementing the comparisons without operator overloading
> would be preferable? I know that APInt does this, so it wouldn't be
> unprecedented in the codebase -- I was just trying to fit the existing code
> without changing too much, but maybe that's the wrong approach.

No, I think keep the code changes to a minimum is important.

And the problems will only be on scalable vs. non-scalable, which is
non-existent today, so not expecting anything current to break.


> I'll take a look through some uses of DataLayout to see how well that would
> work.

Thanks! If we can solve that in a simple way, good. If not, I don't
see it as a big deal, for now.


> That's correct, but data vectors (Z registers) and predicate vectors
> (P registers) have different unit vector sizes: 128bits vs 16bits,
> respectively.

Ah, I see. I imagine P regs will need padding to the maximum alignment
in (almost?) all cases.

cheers,
--renato


More information about the llvm-dev mailing list