[llvm-dev] [RFC][SVE] Supporting SIMD instruction sets with variable vector lengths (original) (raw)

Renato Golin via llvm-dev llvm-dev at lists.llvm.org
Thu Oct 11 07:57:18 PDT 2018

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

More information about the llvm-dev mailing list