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

[Renato Golin via llvm-dev]

Hi Graham,

On Thu, 11 Oct 2018 at 15:14, Graham Hunter <Graham.Hunter at arm.com> wrote:
>   1. I've changed Type::getPrimitiveSizeInBits to return 0 for vector types
>      and changed all uses of it with vector types to use
>      Type::getScalableSizeInBits instead, following the design in the RFC.
>
>      While this shows where getPrimitiveSizeInBits is used with vector types,
>      I think it would be better for now to change it back to avoid breaking
>      existing targets and put an assert in it to ensure that it's only used
>      on non-scalable vectors. We can revisit the decision later once
>      scalable vector support is more mature. Thoughts?

Another solution would be to make it return ScalableSize.Unscaled. At
least in a transition period.


>   2. There are two implementations of ScalableSize; one in Type.h, and one
>      in DataLayout.h. I'd prefer to only have one, but the former reports
>      sizes as 32bits while the latter uses 64bits.
>
>      I think changing all size queries to use 64bits is the best way to
>      resolve it -- are there any significant problems with that approach
>      aside from lots of code churn?
>
>      It would also be possible to use templates and typedefs, but I figure
>      unifying size reporting would be better.

Agreed.


>   3. I have only implemented 'strict' comparisons for now, which leads to
>      some possibly-surprising results; {X, 0} compared with {0, X} will
>      return false for both '==' and '<' comparisons, but true for '<='.
>
>      I think that supporting 'maybe' results from overloaded operators
>      would be a bad idea, so if/when we find cases where they are needed
>      then I think new functions should be written to cover those cases
>      and only used where it matters. For simple things like stopping
>      casts between scalable and non-scalable vectors the strict
>      comparisons should suffice.

How do you differentiate between maybe and certain?

Asserts making sure you never compare scalable with non-scalable in
the wrong way would be heavy handed, but are the only sure way to
avoid this pitfall.

A handler to make those comparisons safe (for example, returning
safety breach via argument pointer) would be lighter, but require big
code changes and won't work with overloaded operators.


>   4. Alignment for structs containing scalable types is tricky. For now,
>      I've added an assert to force all structs containing scalable vectors
>      to be packed.

I take it by "alignment" you mean element size (== structure size),
not structure alignment, which IIUC, only depends on the ABI.

I remember vaguely that scalable vectors' alignment in memory is the
same as the unit vector's, and the unit vector is known at compile
time, just not the multiplicity.

Did I get that wrong?


>      It won't be possible to calculate correct offsets at compile time if
>      the minimum size of a struct member isn't a multiple of the required
>      alignment for the subsequent element(s).

I assume this would be either an ABI decision or an extension to the
standard, but we can re-use C99's VLA concepts, only here it's the
element size that is unknown, not just the element count.

This would keep the costs of unknown offsets until runtime to a minimal.

It would also make sure undefined behaviour while accessing
out-of-bounds offsets in a structure with SVE types break consistently
and early. :)

cheers,
--renato