[LangRef] Update text for vscale to be more flexible but maintain original intent.

[paulwalker-arm]

Summary

llvm/docs/AArch64SME.rst contains a set of design decisions that
include controlled ways for an AArch64 binary to support multiple
values of vscale during program execution albeit not at the same time.

However, the LangRef prohibits this by requiring vscale to be constant
throughout the whole execution of a binary. This is overly restrictive
as limiting to function call boundaries should be sufficient.

Such a change does not affect existing code because changes of vscale
must be well defined within the IR (e.g. function attributes) of which
nothing exists prior to LLVM16 and so original behaviour is maintained.
For example, traditional function inlining can continue because while
the new definition allows the caller and callee to have different
vscales, neither function contain any decoration that allows such a
transition and thus it's safe to assume there is none. Essentially,
all complexity is pushed onto the implementors of vscale changing
behaviour

[paulwalker-arm]

I've create this patch in response to D131562's review comments. I've deliberately tried to keep things simple as I believe the complexity of what is and isn't allowed during a transition belongs with the mechanism that instigates the transition. I've also simplified the description of llvm.vscale rather than duplicate the finer details.

[nikic]

I don't think we can allow this as long as vscale constant expressions are supported (these are currently represented via gep of scalable type). I am rather strongly opposed to having constants that are not in fact constant, so this change should only happen after a migration towards llvm.vscale intrinsics.

[aemerson]

In D134648#3815329, @nikic wrote:

I don't think we can allow this as long as vscale constant expressions are supported (these are currently represented via gep of scalable type). I am rather strongly opposed to having constants that are not in fact constant, so this change should only happen after a migration towards llvm.vscale intrinsics.

I haven't been following the scalable types story in a lot of detail, but doesn't disallowing GEP of scalable types imply that pointer calculations need to be done via decomposed integer arithmetic? Does this break for non-integral pointer types?

[paulwalker-arm]

In D134648#3817518, @aemerson wrote:

In D134648#3815329, @nikic wrote:

I don't think we can allow this as long as vscale constant expressions are supported (these are currently represented via gep of scalable type). I am rather strongly opposed to having constants that are not in fact constant, so this change should only happen after a migration towards llvm.vscale intrinsics.

I haven't been following the scalable types story in a lot of detail, but doesn't disallowing GEP of scalable types imply that pointer calculations need to be done via decomposed integer arithmetic? Does this break for non-integral pointer types?

I believe the ask here relates only to GEP based ConstantExpr expressions and is presumably part of the wider effort to limit how ConstantExprs are used. I don't object to the proposal as I've never liked this representation of vscale as to my mind it doesn't consider how DataLayout could mean the result isn't quite what you'd expect.

[efriedma]

Killing off GEP constant expressions that involve indexing over a scalable type sounds like a fine idea. (I think we want to keep GEP instructions over scalable types... I mean, I guess we could get rid of them, but that seems more complicated.)

[tschuett]

I am still in favour of llvm.aarch64.sme.vscale().

[nikic]

In D134648#3817518, @aemerson wrote:

In D134648#3815329, @nikic wrote:

I don't think we can allow this as long as vscale constant expressions are supported (these are currently represented via gep of scalable type). I am rather strongly opposed to having constants that are not in fact constant, so this change should only happen after a migration towards llvm.vscale intrinsics.

I haven't been following the scalable types story in a lot of detail, but doesn't disallowing GEP of scalable types imply that pointer calculations need to be done via decomposed integer arithmetic? Does this break for non-integral pointer types?

Arbitrary arithmetic on pointers is represented via getelementptr i8, ptr %p, i64 %offset, it's not necessary (and highly undesirable) to drop down to ptrtoint + add + inttoptr.

For vscale in particular, it's not necessary to go that far:

%gep = getelementptr <vscale x N x %T>, ptr %p, i64 %index
; Is equivalent to
%vscale = call i64 @llvm.vscale.i64()
%scaled.index = mul i64 %index, %vscale
%gep = getelementptr <N x %T>, ptr %p, i64 %scaled.index

Though for the purposes of this change, I'm mainly concerned about the constant expression case, which would no longer be well-defined if vscale is non-constant. I think constant scalable GEPs are mostly used to represent vscale itself (using something like ptrtoint (ptr getelementptr (<vscale x 1 x i8>, ptr null, i64 1) to i64)).

Removing scalable GEPs entirely would also be beneficial, because our current support for scalable GEPs tends to be of the "just don't crash" kind and adding proper support for them is associated with a lot of additional complexity. On the other hand, a llvm.vscale-based representation "just works", e.g. BasicAA would be able to reason about it without further changes. But that's kind of orthogonal to this particular change.

[aemerson]

In D134648#3819122, @tschuett wrote:

I am still in favour of llvm.aarch64.sme.vscale().

I'm not sure this solves the problem, as after a transition to streaming mode, the value returned by vanilla vscale() will also be different.

[aemerson]

In D134648#3819225, @nikic wrote:

In D134648#3817518, @aemerson wrote:

In D134648#3815329, @nikic wrote:

I don't think we can allow this as long as vscale constant expressions are supported (these are currently represented via gep of scalable type). I am rather strongly opposed to having constants that are not in fact constant, so this change should only happen after a migration towards llvm.vscale intrinsics.

I haven't been following the scalable types story in a lot of detail, but doesn't disallowing GEP of scalable types imply that pointer calculations need to be done via decomposed integer arithmetic? Does this break for non-integral pointer types?

Arbitrary arithmetic on pointers is represented via getelementptr i8, ptr %p, i64 %offset, it's not necessary (and highly undesirable) to drop down to ptrtoint + add + inttoptr.

For vscale in particular, it's not necessary to go that far:

%gep = getelementptr <vscale x N x %T>, ptr %p, i64 %index
; Is equivalent to
%vscale = call i64 @llvm.vscale.i64()
%scaled.index = mul i64 %index, %vscale
%gep = getelementptr <N x %T>, ptr %p, i64 %scaled.index

Though for the purposes of this change, I'm mainly concerned about the constant expression case, which would no longer be well-defined if vscale is non-constant. I think constant scalable GEPs are mostly used to represent vscale itself (using something like ptrtoint (ptr getelementptr (<vscale x 1 x i8>, ptr null, i64 1) to i64)).

Removing scalable GEPs entirely would also be beneficial, because our current support for scalable GEPs tends to be of the "just don't crash" kind and adding proper support for them is associated with a lot of additional complexity. On the other hand, a llvm.vscale-based representation "just works", e.g. BasicAA would be able to reason about it without further changes. But that's kind of orthogonal to this particular change.

Sure, my point was that removing scalable GEPs entirely would mean that some hypothetical architecture with non-integral pointers and scalable types would be relying on GEP for address materialization, as plain integer arithmetic wouldn't work. So to me it seems we can only remove the constant expressions.

[tschuett]

In D134648#3819317, @aemerson wrote:

In D134648#3819122, @tschuett wrote:

I am still in favour of llvm.aarch64.sme.vscale().

I'm not sure this solves the problem, as after a transition to streaming mode, the value returned by vanilla vscale() will also be different.

llvm.vscale() would still return the sve-scale.

[aemerson]

In D134648#3819413, @tschuett wrote:

In D134648#3819317, @aemerson wrote:

In D134648#3819122, @tschuett wrote:

I am still in favour of llvm.aarch64.sme.vscale().

I'm not sure this solves the problem, as after a transition to streaming mode, the value returned by vanilla vscale() will also be different.

llvm.vscale() would still return the sve-scale.

Sorry if I'm misunderstanding you. After a transition to streaming mode, all SVE vectors become SVL length. If you were to use llvm.vscale() to compute a vector's size in this mode, it *must* return the same value as llvm.aarch64.sme.vscale(). In the case of streaming compatible functions which may be executing in any mode, I don't think you can know which intrinsic to call at compile time in order to get the correct vector length.

[paulwalker-arm]

Although SME is my rational I'd rather keep things in the context of LLVM IR rather than any specific implementation. It is not the intent of this change to represent multiple values of vscale concurrently and thus we do not need a way to query anything but the current value of vscale. Please also remember that we're talking about more than just an intrinsic. llvm.vscale() returns the value of vscale from <vscale x 2 x i64>. If we were to add another intrinsic, say llvm.another_vscale(), then that implies we'd need a new vector type of the form <another_vscale x 2 x i64>, which is not something we need for SME enablement.

[tschuett]

llvm.vscale() denotes vl and llvm.aarch64.sme.vscale() denotes svl. From the context you should know which one you need.

You want to change the semantics of vscale in a Phabricator Diff without an RFC on Discourse?

[aemerson]

In D134648#3820765, @tschuett wrote:

llvm.vscale() denotes vl and llvm.aarch64.sme.vscale() denotes svl. From the context you should know which one you need.

There are times, such as in streaming-compatible functions, where it's unknown at compile time which mode is active.

You want to change the semantics of vscale in a Phabricator Diff without an RFC on Discourse?

I think this patch was made in good faith in response to requests for a langref update in another patch.

[efriedma]

In D134648#3820765, @tschuett wrote:

You want to change the semantics of vscale in a Phabricator Diff without an RFC on Discourse?

We can start a Discourse thread for wider exposure, sure.

[paulwalker-arm]

Ping now the work to disallow vscale constant expressions is complete (D145404).

Shortly after creating the original patch I started an RFC (https://discourse.llvm.org/t/proposed-langref-change-to-relax-the-constness-of-vscale) with the only response being a link to another discussion where the tone was "this is what we wanted all along".

[nikic]

llvm/docs/LangRef.rst

3693

I'm not sure I understand what "is tightly controlled by function attributes" means here.

Is it possible for a function with one vscale value to call a function with another vscale value? How does vscale change in that case, and what prevents inlining of such functions?

llvm/docs/LangRef.rst

 ::
 
       < <# elements> x <elementtype> >          ; Fixed-length vector
       < vscale x <# elements> x <elementtype> > ; Scalable vector
 
 The number of elements is a constant integer value larger than 0;
 elementtype may be any integer, floating-point or pointer type. Vectors
 of size zero are not allowed. For scalable vectors, the total number of
-elements is a constant multiple (called vscale) of the specified number
-of elements; vscale is a positive integer that is unknown at compile time
-and the same hardware-dependent constant for all scalable vectors at run
-time. The size of a specific scalable vector type is thus constant within
-IR, even if the exact size in bytes cannot be determined until run time.
+elements is a multiple (called ``vscale``) of the specified number of elements;
+
+.. _vscale
+
+``vscale`` is a positive integer that is unknown at compile time but has the
+same hardware-dependent value for all scalable vectors in a function. ``vscale``
+can change at function call boundaries but such a change is tightly controlled
+by function attributes and should not be observable to the calling function.
+
+The size of a specific scalable vector type is thus constant within a function,
+even if the exact size in bytes cannot be determined until run time. However,
+care must be taken to limit cross function optimisations if ``vscale`` might
+change.
 
 :Examples:
 
 +------------------------+----------------------------------------------------+
 | ``<4 x i32>``          | Vector of 4 32-bit integer values.                 |
 +------------------------+----------------------------------------------------+
 | ``<8 x float>``        | Vector of 8 32-bit floating-point values.          |
 +------------------------+----------------------------------------------------+

 """""""""
 
 The ``llvm.vscale`` intrinsic returns the value for ``vscale`` in scalable
 vectors such as ``<vscale x 16 x i8>``.
 
 Semantics:
 """"""""""
 
-``vscale`` is a positive value that is constant throughout program
-execution, but is unknown at compile time.
-If the result value does not fit in the result type, then the result is
-a :ref:`poison value <poisonvalues>`.
-
+:ref:`vscale <vscale>` is a positive value that is constant throughout the
+calling function. If the result value does not fit in the result type, then the
+result is a :ref:`poison value <poisonvalues>`.
 
 Stack Map Intrinsics
 --------------------
 
 LLVM provides experimental intrinsics to support runtime patching
 mechanisms commonly desired in dynamic language JITs. These intrinsics
 are described in :doc:`StackMaps`.