Skip to content

various fixes for scalable vectors#153286

Open
davidtwco wants to merge 4 commits intorust-lang:mainfrom
davidtwco:sve-intrinsics
Open

various fixes for scalable vectors#153286
davidtwco wants to merge 4 commits intorust-lang:mainfrom
davidtwco:sve-intrinsics

Conversation

@davidtwco
Copy link
Member

@davidtwco davidtwco commented Mar 2, 2026

View all comments

These are a handful of patches fixing bugs with the current #[rustc_scalable_vector] infrastructure so that we can upstream the intrinsics to stdarch:

  1. Instead of just using regular struct lowering for tuples of scalable vectors, which results in an incorrect ABI (e.g. returning indirectly), we change to using BackendRepr::ScalableVector which will lower to the correct type and be passed in registers.

  2. Clang changed from representing tuples of scalable vectors as structs rather than as wide vectors (that is, scalable vector types where the N part of the <vscale x N x ty> type was multiplied by the number of vectors). rustc mirrored this in the initial implementation of scalable vectors that didn't land.

    When our early patches used the wide vector representation, our intrinsic patches used the legacy llvm.aarch64.sve.tuple.{create,get,set}{2,3,4} intrinsics for creating these tuples/getting/setting the vectors, which were only supported due to LLVM's AutoUpgrade pass converting these intrinsics into llvm.vector.insert. AutoUpgrade only supports these legacy intrinsics with the wide vector representation.

    With the current struct representation, Clang has special handling in codegen for generating insertvalue/extractvalue instructions for these operations, which must be replicated by rustc's codegen for our intrinsics to use.

    We add a new core::intrinsics::scalable module (never intended to be stable, just used by the stdarch intrinsics, gated by core_intrinsics) and add new intrinsics which rustc lowers to the appropriate insertvalue/extractvalue instructions.

  3. Add generation of debuginfo for scalable vectors, following the DWARF that Clang generates.

  4. Some intrinsics need something like simd_cast, which will work for scalable vectors too, so this implements a new sve_cast intrinsic that uses the same internals as simd_cast. This seemed better than permitting scalable vectors to be used with the simd_* intrinsics more generally as I can't guarantee this would work for all of them.

This is a relatively large patch but most of it is tests, and each commit should be relatively standalone. It's a little bit easier to upstream them together to avoid needing to stack them. It's possible that some more compiler fixes will be forthcoming but it's looking like this might be all at the moment.

Depends on #153653

r? @workingjubilee (discussed on Zulip)

@davidtwco davidtwco added the F-scalable-vectors `#[rustc_scalable_vector]` label Mar 2, 2026
@rustbot
Copy link
Collaborator

rustbot commented Mar 2, 2026

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

This PR changes rustc_public

cc @oli-obk, @celinval, @ouz-a, @makai410

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

@rustbot rustbot added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Mar 2, 2026
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Mar 2, 2026
@rustbot
Copy link
Collaborator

rustbot commented Mar 2, 2026

workingjubilee is currently at their maximum review capacity.
They may take a while to respond.

@rust-log-analyzer

This comment has been minimized.

@rustbot

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment was marked as resolved.

@rustbot
Copy link
Collaborator

rustbot commented Mar 2, 2026

triagebot.toml has been modified, there may have been changes to the review queue.

cc @wesleywiser

@rustbot rustbot added the A-meta Area: Issues & PRs about the rust-lang/rust repository itself label Mar 2, 2026
@rust-log-analyzer

This comment was marked as resolved.

@rustbot
Copy link
Collaborator

rustbot commented Mar 2, 2026

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

@rust-log-analyzer

This comment was marked as resolved.

@rust-log-analyzer

This comment has been minimized.

@rustbot

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-bors

This comment was marked as resolved.

@rustbot

This comment has been minimized.

@lqd
Copy link
Member

lqd commented Mar 10, 2026

Just to hopefully make this easier to review and help Jubilee, could you, for a start, extract the first three commits into a different PR and assign it to me?

@davidtwco
Copy link
Member Author

Just to hopefully make this easier to review and help Jubilee, could you, for a start, extract the first three commits into a different PR and assign it to me?

Split into #153653

JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Mar 10, 2026
scalable vector: type renames and simple checks

Split out from rust-lang#153286

Per rust-lang#153286 (comment), renames `VectorKind` type to `SimdVectorKind` and `BackendRepr::ScalableVector` to `BackendRepr::SimdScalableVector`. Also adds a new check in `rustc_hir_analysis` enforcing that tuples of scalable vectors should only up to eight vectors.

r? @lqd
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Mar 10, 2026
scalable vector: type renames and simple checks

Split out from rust-lang#153286

Per rust-lang#153286 (comment), renames `VectorKind` type to `SimdVectorKind` and `BackendRepr::ScalableVector` to `BackendRepr::SimdScalableVector`. Also adds a new check in `rustc_hir_analysis` enforcing that tuples of scalable vectors should only up to eight vectors.

r? @lqd
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Mar 10, 2026
scalable vector: type renames and simple checks

Split out from rust-lang#153286

Per rust-lang#153286 (comment), renames `VectorKind` type to `SimdVectorKind` and `BackendRepr::ScalableVector` to `BackendRepr::SimdScalableVector`. Also adds a new check in `rustc_hir_analysis` enforcing that tuples of scalable vectors should only up to eight vectors.

r? @lqd
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Mar 10, 2026
scalable vector: type renames and simple checks

Split out from rust-lang#153286

Per rust-lang#153286 (comment), renames `VectorKind` type to `SimdVectorKind` and `BackendRepr::ScalableVector` to `BackendRepr::SimdScalableVector`. Also adds a new check in `rustc_hir_analysis` enforcing that tuples of scalable vectors should only up to eight vectors.

r? @lqd
rust-timer added a commit that referenced this pull request Mar 11, 2026
Rollup merge of #153653 - davidtwco:sve-cleanups, r=lqd

scalable vector: type renames and simple checks

Split out from #153286

Per #153286 (comment), renames `VectorKind` type to `SimdVectorKind` and `BackendRepr::ScalableVector` to `BackendRepr::SimdScalableVector`. Also adds a new check in `rustc_hir_analysis` enforcing that tuples of scalable vectors should only up to eight vectors.

r? @lqd
@rust-bors

This comment was marked as resolved.

@rustbot

This comment has been minimized.

github-actions bot pushed a commit to rust-lang/rustc-dev-guide that referenced this pull request Mar 16, 2026
scalable vector: type renames and simple checks

Split out from rust-lang/rust#153286

Per rust-lang/rust#153286 (comment), renames `VectorKind` type to `SimdVectorKind` and `BackendRepr::ScalableVector` to `BackendRepr::SimdScalableVector`. Also adds a new check in `rustc_hir_analysis` enforcing that tuples of scalable vectors should only up to eight vectors.

r? @lqd
Copy link
Member

@workingjubilee workingjubilee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a weird nit... not that noting a typo is weird, but rather that it is on a commit message.

The PR looks correct otherwise. I'm going to doublecheck the debuginfo part after a nap and approve the PR then assuming I don't find anything worth noting past that commit message nit. Feel free to rebase.

View changes since this review

Instead of just using regular struct lowering for these types, which
results in an incorrect ABI (e.g. returning indirectly), use
`BackendRepr::ScalableVector` which will lower to the correct type and
be passed in registers.

This also enables some simplifications for generating alloca of scalable
vectors and greater re-use of `scalable_vector_parts`.

A LLVM codegen test demonstrating the changed IR this generates is
included in the next commit alongside some intrinsics that make these
tuples usable.
@rustbot
Copy link
Collaborator

rustbot commented Mar 17, 2026

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.

Copy link
Member

@workingjubilee workingjubilee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I wound up having a question about the intrinsic as presented in the standard library. I had missed a detail on my first scan.

View changes since this review


let number_of_elements: u64 = (element_count as u64) * (number_of_vectors.0 as u64);
let number_of_elements_per_vg = number_of_elements / 2;
let mut expr = smallvec::SmallVec::<[u64; 9]>::new();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. Are we really saving much overhead with such a large "SmallVec"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy to change it if it isn't worth it

Comment on lines +1190 to +1197
let vector_ty = llvm::LLVMRustDICreateVectorType(
di_builder,
/* Size */ 0,
layout.align.bits() as u32,
element_di_node,
subscripts,
bitstride,
);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe we should define this as an argument struct if we have to comment... I'll open an issue.

I take it the given size is "0" because it is indeterminate, and we're just trusting the debugger to figure that out from the subrange expression being there? Or does the argument go unused...?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The debuginfo change is largely porting what Clang generates for its scalable vectors, which I've presumed matches what the debuggers expect to find so that they work correctly - I presume the 0 indicates the vector is scalable and that the debugger should use the subrange with the expression to determine the size dynamically.

Comment on lines +22 to +26
#[cfg(target_arch = "aarch64")]
#[rustc_intrinsic]
#[rustc_nounwind]
#[target_feature(enable = "sve")]
pub unsafe fn sve_cast<T, U>(x: T) -> U;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this target_feature annotation necessary? Most of the intrinsics in the supermodule are not THAT kind of intrinsic... they are expected to generate code based on the surrounding features correctly without requiring repeating specifications for each architecture, because they address a pretty fundamental concept usually.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't even think the concept here for tuples are specific in a meaningful way to AArch64 SVE, RISCV has its weird register group thingies that are Basically Also Homogenous Tuples.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added them just to try and limit the chance that they're used incorrectly, figuring it was easy to remove the annotation if we wanted to. I don't know enough about RVV to know if these intrinsics would be useful for them or if they'd need changes (I think they might still use the wide vector representation, so the tuple intrinsics might not be useful to them, and whether they use sve_cast would depend on their intrinsic definitions probably),

Clang changed to representing tuples of scalable vectors as
structs rather than as wide vectors (that is, scalable vector types
where the `N` part of the `<vscale x N x ty>` type was multiplied by
the number of vectors). rustc mirrored this in the initial implementation
of scalable vectors.

Earlier versions of our patches used the wide vector representation and
our intrinsic patches used the legacy
`llvm.aarch64.sve.tuple.{create,get,set}{2,3,4}` intrinsics for creating
these tuples/getting/setting the vectors, which were only supported
due to LLVM's `AutoUpgrade` pass converting these intrinsics into
`llvm.vector.insert`. `AutoUpgrade` only supports these legacy intrinsics
with the wide vector representation.

With the current struct representation, Clang has special handling in
codegen for generating `insertvalue`/`extractvalue` instructions for
these operations, which must be replicated by rustc's codegen for our
intrinsics to use. This patch implements new intrinsics in
`core::intrinsics::scalable` (mirroring the structure of
`core::intrinsics::simd`) which rustc lowers to the appropriate
`insertvalue`/`extractvalue` instructions.
Generate debuginfo for scalable vectors, following the structure that
Clang generates for scalable vectors.
Abstract over the existing `simd_cast` intrinsic to implement a new
`sve_cast` intrinsic - this is better than allowing scalable vectors to
be used with all of the generic `simd_*` intrinsics.
makai410 pushed a commit to makai410/rustc_public that referenced this pull request Mar 19, 2026
scalable vector: type renames and simple checks

Split out from rust-lang/rust#153286

Per rust-lang/rust#153286 (comment), renames `VectorKind` type to `SimdVectorKind` and `BackendRepr::ScalableVector` to `BackendRepr::SimdScalableVector`. Also adds a new check in `rustc_hir_analysis` enforcing that tuples of scalable vectors should only up to eight vectors.

r? @lqd
makai410 pushed a commit to makai410/rustc_public that referenced this pull request Mar 19, 2026
scalable vector: type renames and simple checks

Split out from rust-lang/rust#153286

Per rust-lang/rust#153286 (comment), renames `VectorKind` type to `SimdVectorKind` and `BackendRepr::ScalableVector` to `BackendRepr::SimdScalableVector`. Also adds a new check in `rustc_hir_analysis` enforcing that tuples of scalable vectors should only up to eight vectors.

r? @lqd
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-meta Area: Issues & PRs about the rust-lang/rust repository itself F-scalable-vectors `#[rustc_scalable_vector]` S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants