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

[Chris Lattner via Phabricator via llvm-commits]

lattner added a comment.

In https://reviews.llvm.org/D32737#760373, @rengolin wrote:

> In https://reviews.llvm.org/D32737#760289, @lattner wrote:
>
> >
>
>
> 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.


I'm familiar with it: I was involved in the work at apple (years ago) which contributed to SVE happening with this design.

> I just want to make sure that we take the right *technical* decision now and evolve as needed.

This is obviously correct.

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

This is much more up for debate.  Details matter.  Compilers are a set of engineering tradeoffs.  You need to explain and defend your position carefully, not just state it as though it were "obviously true".

Do you have a discussion somewhere of the overall design of the extensions you're proposing?  This is presumably only a small piece of it.

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

You haven't proposed a set of IR type system extensions.  If you're proposing a new first class type, one which represents a vector of an unknown length, then you'll need to be able to load and store it, e.g. to spill a virtual register.  How much stack space is required for that spill?

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

Seriously, I happen to be very familiar with the hardware/implementation model of this instruction set extension.

The thing that matters here is the specific set of IR extensions you're proposing.  In this patch you're proposing introducing a vscale constant.  This doesn't make sense, because it cannot be used in (e.g.) a global variable initializer, and otherwise doesn't fit the model for constants.  Why not use an intrinsic to return this value?

-Chris


https://reviews.llvm.org/D32737