Uh oh!
There was an error while loading. Please reload this page.
stabilize s390x vector registers - #154184
Conversation
This comment has been minimized.
This comment has been minimized.
2986c81 to
ba604f5Compare
This comment has been minimized.
This comment has been minimized.
ba604f5 to
e182fefCompareUh oh!
There was an error while loading. Please reload this page.
traviscross
commented
Mar 25, 2026
Thanks @folkertdev; I'll be looking to see that @Amanieu confirms this is OK after the back and force. @rfcbot fcp merge lang |
Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns. |
scottmcm
commented
Mar 25, 2026
rust-rfcbot
commented
Mar 25, 2026
🔔 This is now entering its final comment period, as per the review above. 🔔 |
rust-rfcbot
commented
Apr 4, 2026
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. |
folkertdev
commented
Apr 8, 2026
@bors r=Amanieu |
…uwer Rollup of 15 pull requests Successful merges: - #153995 (Use convergent attribute to funcs for GPU targets) - #154184 (stabilize s390x vector registers) - #151898 (constify DoubleEndedIterator) - #154235 (remove unnecessary variables and delimiter check) - #154473 (move borrow checker tests) - #154745 (Replace span_look_ahead with span_followed_by) - #154778 (make field representing types invariant over the base type) - #154867 (Fix private fields diagnostics and improve error messages) - #154879 (Don't store `pattern_ty` in `TestableCase`) - #154910 (Suppress `unreachable_code` lint in `derive(PartialEq, Clone)`) - #154923 (Fix ICE in next-solver dyn-compatibility check) - #154934 (Add getters for `rustc_pattern_analysis::constructor::Slice` fields) - #154938 (match exhaustiveness: Show the guard exhaustivity note only when it's the guards alone that cause non-exhaustiveness) - #154961 (Use derived impl for `GappedRange` subdiagnostic) - #154980 (rustc-dev-guide subtree update)
Uh oh!
There was an error while loading. Please reload this page.
Rollup merge of #154184 - folkertdev:stabilize-s390x-vector-registers, r=Amanieu stabilize s390x vector registers tracking issue: #133416 reference PR: rust-lang/reference#2215 Stabilizes s390x vector registers, e.g. ```rust unsafe fn vreg_128(x: i128) -> i128 { let y; asm!("vlr {}, {}", out(vreg) y, in(vreg) x); y } ``` The types that are accepted for vreg registers are - all float types `f16`, `f32`, `f64`, `f128` - integer types `i32`, `i64` and `i128` and their unsigned counterparts - integer vector types `i8x16`, `i16x8`, `i32x4`, `i64x2` and their unsigned counterparts - float vector types `f16x8`, `f32x4` and `f64x2` Support for all of these is tested in https://github.com/rust-lang/rust/blob/main/tests/assembly-llvm/asm/s390x-types.rs, and the types correspond with the LLVM definition in https://github.com/llvm/llvm-project/blob/df9eb79970c012990e829d174d181d575d414efe/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L312-L339 The `f16`, `f16x8` and `f128` types are unstable, and so can't be used on stable in practice. They do show up in some error messages though. `vreg` was previously only accepted as a clobber. --- Currently the vector types in `core::arch::s390x` are still unstable. Separately stabilizing `vreg` is still useful because scalar types can also be put into `vreg`s. ## Implementation history - #131664 - #150826 cc @uweigand@taiki-e r? @Amanieu
…uwer Rollup of 15 pull requests Successful merges: - rust-lang/rust#153995 (Use convergent attribute to funcs for GPU targets) - rust-lang/rust#154184 (stabilize s390x vector registers) - rust-lang/rust#151898 (constify DoubleEndedIterator) - rust-lang/rust#154235 (remove unnecessary variables and delimiter check) - rust-lang/rust#154473 (move borrow checker tests) - rust-lang/rust#154745 (Replace span_look_ahead with span_followed_by) - rust-lang/rust#154778 (make field representing types invariant over the base type) - rust-lang/rust#154867 (Fix private fields diagnostics and improve error messages) - rust-lang/rust#154879 (Don't store `pattern_ty` in `TestableCase`) - rust-lang/rust#154910 (Suppress `unreachable_code` lint in `derive(PartialEq, Clone)`) - rust-lang/rust#154923 (Fix ICE in next-solver dyn-compatibility check) - rust-lang/rust#154934 (Add getters for `rustc_pattern_analysis::constructor::Slice` fields) - rust-lang/rust#154938 (match exhaustiveness: Show the guard exhaustivity note only when it's the guards alone that cause non-exhaustiveness) - rust-lang/rust#154961 (Use derived impl for `GappedRange` subdiagnostic) - rust-lang/rust#154980 (rustc-dev-guide subtree update)
tracking issue: #133416
reference PR: rust-lang/reference#2215
Stabilizes s390x vector registers, e.g.
The types that are accepted for vreg registers are
f16,f32,f64,f128i32,i64andi128and their unsigned counterpartsi8x16,i16x8,i32x4,i64x2and their unsigned counterpartsf16x8,f32x4andf64x2Support for all of these is tested in https://github.com/rust-lang/rust/blob/main/tests/assembly-llvm/asm/s390x-types.rs, and the types correspond with the LLVM definition in https://github.com/llvm/llvm-project/blob/df9eb79970c012990e829d174d181d575d414efe/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L312-L339
The
f16,f16x8andf128types are unstable, and so can't be used on stable in practice. They do show up in some error messages though.vregwas previously only accepted as a clobber.Currently the vector types in
core::arch::s390xare still unstable. Separately stabilizingvregis still useful because scalar types can also be put intovregs.Implementation history
f16inline ASM support for s390x #150826cc @uweigand@taiki-e
r? @Amanieu