various fixes for scalable vectors#153286
Conversation
|
|
This comment has been minimized.
This comment has been minimized.
ed74abe to
dc9af49
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
dc9af49 to
06b46c4
Compare
This comment was marked as resolved.
This comment was marked as resolved.
06b46c4 to
4329945
Compare
|
cc @wesleywiser |
This comment was marked as resolved.
This comment was marked as resolved.
4329945 to
ab6b50b
Compare
ab6b50b to
5fc0060
Compare
This comment was marked as resolved.
This comment was marked as resolved.
5fc0060 to
f8b4bc8
Compare
This comment has been minimized.
This comment has been minimized.
f8b4bc8 to
cfb2032
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
b904ac4 to
f323831
Compare
This comment was marked as resolved.
This comment was marked as resolved.
f323831 to
3c65b93
Compare
This comment has been minimized.
This comment has been minimized.
|
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 |
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
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
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
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
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
This comment was marked as resolved.
This comment was marked as resolved.
3c65b93 to
345b28e
Compare
This comment has been minimized.
This comment has been minimized.
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
There was a problem hiding this comment.
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.
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.
345b28e to
b0b5ef1
Compare
|
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. |
|
|
||
| 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(); |
There was a problem hiding this comment.
Hmm. Are we really saving much overhead with such a large "SmallVec"?
There was a problem hiding this comment.
I'm happy to change it if it isn't worth it
| let vector_ty = llvm::LLVMRustDICreateVectorType( | ||
| di_builder, | ||
| /* Size */ 0, | ||
| layout.align.bits() as u32, | ||
| element_di_node, | ||
| subscripts, | ||
| bitstride, | ||
| ); |
There was a problem hiding this comment.
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...?
There was a problem hiding this comment.
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.
| #[cfg(target_arch = "aarch64")] | ||
| #[rustc_intrinsic] | ||
| #[rustc_nounwind] | ||
| #[target_feature(enable = "sve")] | ||
| pub unsafe fn sve_cast<T, U>(x: T) -> U; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
b0b5ef1 to
003827f
Compare
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
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
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: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::ScalableVectorwhich will lower to the correct type and be passed in registers.Clang changed from representing tuples of scalable vectors as structs rather than as wide vectors (that is, scalable vector types where the
Npart 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'sAutoUpgradepass converting these intrinsics intollvm.vector.insert.AutoUpgradeonly supports these legacy intrinsics with the wide vector representation.With the current struct representation, Clang has special handling in codegen for generating
insertvalue/extractvalueinstructions for these operations, which must be replicated by rustc's codegen for our intrinsics to use.We add a new
core::intrinsics::scalablemodule (never intended to be stable, just used by the stdarch intrinsics, gated bycore_intrinsics) and add new intrinsics which rustc lowers to the appropriateinsertvalue/extractvalueinstructions.Add generation of debuginfo for scalable vectors, following the DWARF that Clang generates.
Some intrinsics need something like
simd_cast, which will work for scalable vectors too, so this implements a newsve_castintrinsic that uses the same internals assimd_cast. This seemed better than permitting scalable vectors to be used with thesimd_*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)