rustc_scalable_vector(N)

[davidtwco]

Supercedes #118917.

Initial experimental implementation of rust-lang/rfcs#3838. Introduces a rustc_scalable_vector(N) attribute that can be applied to types with a single [$ty] field (for u{16,32,64}, i{16,32,64}, f{32,64}, bool). rustc_scalable_vector types are lowered to scalable vectors in the codegen backend.

As with any unstable feature, there will necessarily be follow-ups as we experiment and find cases that we've not considered or still need some logic to handle, but this aims to be a decent baseline to start from.

See #145052 for request for a lang experiment.

[rustbot]

r? @compiler-errors

rustbot has assigned @compiler-errors.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

Some changes occurred in compiler/rustc_attr_data_structures

cc @jdonszelmann

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred to the platform-builtins intrinsics. Make sure the
LLVM backend as well as portable-simd gets adapted for the changes.

cc @antoyo, @GuillaumeGomez, @bjorn3, @calebzulawski, @programmerjake

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

changes to the core type system

cc @compiler-errors, @lcnr

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

[davidtwco]

I've changed this back to a draft and marked it as S-waiting-on-author while I rebase it and get the approval for an experimental implementation to go ahead.

[workingjubilee]

I do not intend to have repr(simd) survive this year, so I do not think this should be added.

[davidtwco]

I do not intend to have repr(simd) survive this year, so I do not think this should be added.

Could you elaborate?

[workingjubilee]

I intend to replace it with an approach based on lang items for a variety of reasons, one of them being that to start with, the repr(simd) "attribute" does not compose and should not.

r? @workingjubilee

[Amanieu]

I don't think that making scalable vectors a non-const Sized type will work with SME since the size of scalable vectors can change depending on attributes placed on a function (ACLE spec). This is because there are 2 vector lengths (normal & streaming) and the length can changed based on CPU state. In C, the CPU state is controlled via function attributes, specifically:

• In a normal function, vectors use the normal VL.
• In a locally streaming function, vectors use the streaming VL.
• In a streaming-compatible function, vectors use the VL of their caller.

Additionally, we will need to add compile-time checks to ensure scalable vectors aren't passed as arguments or returned across a mode change (ACLE spec). This essentially means that we can't support the use of scalable vectors in generic function signatures.

I think the better approach is to go back to the original design in #118917 where scalable vectors are essentially extern types to which we add some capabilities. This avoids issues with generics since these types can never be passed as arguments or returned in a generic context.

This design can still make use of the Sized type hierarchy since we still need the distinction between MetaSized and Unsized, with scalable vectors being the latter.

[programmerjake]

In C, the CPU state is controlled via function attributes, specifically:

• In a normal function, vectors use the normal VL.
• In a locally streaming function, vectors use the streaming VL.
• In a streaming-compatible function, vectors use the VL of their caller.

tbh that sounds more like what we want is for Arm's scalable vectors to have a const-generic argument that's implicitly set by the surrounding function's mode which is either known (normal and locally-streaming functions), or a const-generic that's implicitly set by the caller (streaming-compatible functions). passing/returning scalable vectors between incompatible modes would then just produce a type error due to the const-generic argument not matching, but you can pass scalable vectors between compatible modes since the compiler can see the const-generic matches.

[workingjubilee]

@Amanieu My question is essentially as @programmerjake said: is there a reason that the SME and SVE modes are not two-or-more types, then? Whether the mode is a generic parameter or not is not too important to me, but it does seem intuitive to treat it as such. It's not like we can do FFI without knowing the mode, right?

[workingjubilee]

Documentation we'll want to reference while discussing this:

• https://llvm.org/docs/AArch64SME.html

[workingjubilee]

@programmerjake I am sure Amanieu will provide more information, but one thing he pointed out when I asked in another context is that we would have to inhibit usage of SVE and SME types in the same function, because LLVM doesn't support switching modes except on function boundaries.

However, it seems we will have to implement compile-time handling regarding functions for SVE and SME either way, so I suspect using the tools we already have for such would be better. We already have 3 types of functions which each require compile-time checking, after all.

[Amanieu]

I don't think having 2 separate types for SVE and SME vectors is going to work. The main issue is that it's absolutely not possible to have scalable locals of 2 different modes in the same function. LLVM doesn't support it, and for good reason since even calculating the stack offsets for locals would involve several SME/SVE mode switches. The problem is that since these types would be runtime-sized, you would be able to smuggle those types into a function in various ways other than parameters and return values, and there's no way you can enforce this in a generic context.

[Amanieu]

The main advantage of making SVE vectors fully unsized is that it allows us to reliably determine, before monomorphization, whether the signature of a function has SVE locals, parameters or return values. This means that:

• We can always pass these in registers since we can guarantee that both the caller and callee have the sve target feature enabled.
• We don't need to worry about code doing size_of_val(&*sve_ptr) in a generic function that doesn't have the sve target feature because fully unsized types (like extern types) can't be dereferenced.
• Constraints on passing values over the streaming/non-streaming boundary can be enforced pre-monomorphization. This also means that we never have to worry about having both SME and SVE locals in the same function. Arguably it's also possible to achieve this by rejecting any non-const-sized arguments at such boundaries.

The downsides are:

• We can't take the address of an SVE local. This usually isn't needed in practice since intrinsics are normally used to read data into and out of SVE vectors.
• We can't use SVE vectors in generic code that passes or returns such values, since that requires Sized. This also isn't a huge issue in practice since SVE code will tend to stick to SVE intrinsics instead of using generic code.

Overall I think the advantages outweigh the inconvenients and result in a simpler implementation in the compiler. It is also forward-compatible with making these types runtime-sized in the future.

[workingjubilee]

Hmmmm. Only requiring signature checking does help...

I think I'm not overly attached to a specific direction but I'd like to have the FIXMEs reflect our current inclination, at least.

[Amanieu]

I'm happy to land this as it is for now (with scalable vectors being Sized) so we can start working on the library side of SVE. But it's something we should keep in mind for the future.

[davidtwco]

The main advantage of making SVE vectors fully unsized is that it allows us to reliably determine, before monomorphization, whether the signature of a function has SVE locals, parameters or return values.

Maybe I'm missing something, but how does making the vectors fully unsized let us determine that? You can still write generic functions that can be instantiated by fully unsized types:

#![feature(extern_types)]
#![feature(sized_hierarchy)]
use std::marker::PointeeSized;

unsafe extern "C" {
    type Bar;
    
    fn get_bar() -> &'static Bar;
}

fn foo<T: PointeeSized>(x: &T) {}

fn main() {
    foo::<Bar>(unsafe { get_bar() });
}

In this example, Bar is an extern type because those exist today but it could be a SVE type and we wouldn't be able to know pre-mono whether the signature of foo will be instantiated with SVE type Bar.

The other disadvantage of making them fully unsized is that they can't be locals or return types or implement Copy without lots of special-casing (as this requires Sized today), and as they're just values in registers, they ought to be able to do those things.

I've been thinking of the sizedness of these types as a distinct problem from what we do about streaming-vs-non-streaming and all of the issues related to these types needing the SVE target feature. If they are non-const Sized, then we can make these locals/return types/Copy and that improves their usability within functions. Irrespective of their sizedness, we can still argue that they need to be special-cased to prevent generic instantiation, so that we can enforce the streaming/non-streaming boundary and anything else we need, or if we can think of a better solution then we can do that instead.

[davidtwco]

Oh, I understand now what you meant by making the types fully unsized enabling us to determine whether there are locals, parameters or return types: because the generic parameter won't implement Sized and the compiler will require that for the locals, parameters or return types, not that it will somehow let us prevent the instantiation of generic functions more generally for those types.

Nevertheless, I think my point is still the same, that we could make them non-const Sized and usable as locals and return types in SVE-enabled functions, and consider the limitations on generic instantiation a separate thing, giving us a bit more usability.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[workingjubilee]

It's also unclear whether we will ever be able to enable the compiler to have more ambiguously-sized argument and return types in the future. I think we eventually will want to explicitly ban what we want to ban rather than relying on some other element of the language "doing it for us". If nothing else, for the sake of producing a better error message, at least. That doesn't have to be addressed here, obviously.

[workingjubilee]

This can just be u64. We will only parse 0..=u64::MAX and we will reject with an error things larger than 2.pow(16).

[workingjubilee]

I feel almost like we should say "factor" instead of "count" since the "actual count" is unknown until runtime but uses the N provided here as a factor, but then syntactically the count is whatever was given in the attribute, but then... anyway, either is good.

[davidtwco]

I ended up changing it to u16 throughout as the attribute parsing pretty printer already had an impl for that and u128, not a particularly great reason, but 65535 is more than enough for this attribute.

[workingjubilee]

This seems like the wrong answer, they should be definitionally homogeneous, but maybe it's because we produce incorrect code if we answer as homogeneous?

[davidtwco]

The original PR that this was based on did return Homogenous and added a new RegKind and so on, but I worked out that it was basically all dead code, even this line as it was when you reviewed.

classify_arg and classify_ret were bailing out earlier than the call to is_homogeneous_aggregate and it was keeping the PassMode::Direct that the function was called with, which I think is correct and works fine. I've added an explicit condition to bail out for scalable vectors in this case just so that happening is more obvious, and I've changed this to a unreachable! as it shouldn't be hit.

[workingjubilee]

That last scan-through should be all, unless something is revealed (made apparent?) by the next iteration, so

@rustbot author