[PATCH] D32737: [Constants][SVE] Represent the runtime length of a scalable vector

[Renato Golin via Phabricator via llvm-commits]

rengolin added a comment.

In https://reviews.llvm.org/D32737#760289, @lattner wrote:

> I agree with Chandler on this.  Making something a first class type in LLVM has wide reaching effects, including requiring the ability to load/store/phi the value, pass it by argument, etc.


I don't think anyone disagrees with that point.

> Vikram had a research project many many years ago to do the exact same sort of thing.  It failed because of these and other reasons.

This is not a research project, it's a spec that is being made into hardware by a large number of large corporations and it's in development by a long number of years.

There are already a number of production compilers (including LLVM based) that have SVE implemented in them.

I just want to make sure that we take the right *technical* decision now and evolve as needed. From my point of view, making scalable vectors a native and core type of IR is the only way forward, because the semantics needs to be ingrained in the language to make sense. AFAICS, at the IR level, the differences between vectors and scalable ones is not that big a deal, certainly not bigger than vectors versus scalar.

> What are the semantics of select when the two vectors have different width?

As Sanjoy said, it's illegal behaviour. Vector length is a CPU runtime property, not a vector property. Vectors don't have length.

The IR should consider a scalable vector as a "promise of at least one iteration, but potentially more" of the same computation. The mask vectors do the rest of the job of making sure the semantics stays the same.

> Does store do a memory allocation?

I'm not sure what you mean by that. Loads and stores do nothing more than what AVX512 (with scatter/gather) already does.

The main difference is that all operations (even non-scatter/gather) are predicated, so that there is absolute control over undefined behaviour. The predicate vector is updated from the scalar evolution of the iteration ranges and they control what the actual operations can and can't do, irrespective of the vector size.

cheers,
--renato


https://reviews.llvm.org/D32737