Sync from rust 2026/06/27#899
Merged
Merged
Conversation
Turns out these were all making `OperandValue::Immediate`s already -- the intrinsic always returns a primitive scalar -- so pretty easy to handle. While I was looking at it, I also "rustified" the intrinsic signature a bit: returning a `bool` and taking a generic pointee and `unsafe fn`s cleans up the call in `std` a bit without making the implementation in the backend any harder.
…dianqk Stop needing an alloca for `catch_unwind` Turns out these were all making `OperandValue::Immediate`s already -- the intrinsic always returns a primitive scalar -- so pretty easy to handle. cc rust-lang/rust#153250 rust-lang/compiler-team#970 While I was looking at it, I also "rustified" the intrinsic signature a bit: returning a `bool` and taking a generic pointee and `unsafe fn`s cleans up the call in `std` a bit without making the implementation in the backend any harder. r? dianqk
Couple of changes to help with moving LTO to the link phase Part of rust-lang/compiler-team#908
This commit switches a fixed-size list of `[Option<Reg>; 8]` to instead holding `ArrayVec<Reg, 8>` in the `CastTarget` type used when calculating ABIs. This is inspired by [discussion on Zulip][link] where I'm hoping to in the near future extend the usage of this to possibly beyond 8 elements for a new WebAssembly ABI taking advantage of multi-value. For now though this mostly just switches to array/slice-like idioms of accessors rather than dealing with `Option<Reg>` as the unit. [link]: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Using.20.60ArgAbi.3A.3Amake_direct_deprecated.60/with/598607139
…, r=nnethercote Use a `ArrayVec` in `CastTarget` This commit switches a fixed-size list of `[Option<Reg>; 8]` to instead holding `ArrayVec<Reg, 8>` in the `CastTarget` type used when calculating ABIs. This is inspired by [discussion on Zulip][link] where I'm hoping to in the near future extend the usage of this to possibly beyond 8 elements for a new WebAssembly ABI taking advantage of multi-value. For now though this mostly just switches to array/slice-like idioms of accessors rather than dealing with `Option<Reg>` as the unit. [link]: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Using.20.60ArgAbi.3A.3Amake_direct_deprecated.60/with/598607139
This is an UnordMap internally. Iteration order for the work product map should not matter aside from the place it is serialized where sorting by WorkProductId is sufficient.
Co-authored-by: Taiki Endo <te316e89@gmail.com> Co-authored-by: Kerry Jones <kerry@iodrive.co.za>
asm! support for the Xtensa architecture This implements the asm! support for Xtensa. We've been using this code for a few years in [our fork](https://github.com/esp-rs/rust) and it's been working well. I finally found some time to clean it up a bit and start the upstreaming process. This should be one of the final PRs for Xtensa support on the Rust side (minus bug fixes of course). After this, we're mostly just waiting on the LLVM upstreaming which is going well. This PR doesn't cover all possible asm options for Xtensa, but the base ISA plus a few extras that are used in Espressif chips. r? Amanieu
Add support for inline assembly for the amdgpu backend (the amdgcn-amd-amdhsa target). Add register classes for `vgpr` (vector general purpose register) and `sgpr` (scalar general purpose register). The LLVM backend supports two more classes, `reg`, which is either VGPR or SGPR, up to the compiler to decide. As instructions often rely on a register being either a VGPR or SGPR for the assembly to be valid, reg doesn’t seem that useful (I struggled to write correct tests for it), so I didn’t end up adding it. The fourth register class is AGPRs, which only exist on some hardware versions (not the consumer ones) and they have restricted ways to write and read from them, which makes it hard to write a Rust variable into them. They could be used inside assembly blocks, but I didn’t add them as Rust register class. There are a few change affecting general inline assembly code, that is `InlineAsmReg::name()` now returns a `Cow` instead of a `&'static str`. Because amdgpu has many registers, 256 VGPRs plus combinations of 2 or 4 VGPRs, and I didn’t want to list hundreds of static strings, the amdgpu reg stores the register number(s) and a non-static String is generated at runtime for the register name. Similar for register classes and supported_types. Vectors of 64-bit types are supported by the LLVM backend, but omitted here to make the code simpler. There is currently no systematic support in LLVM of which vectors of 64-bit types are supported. Also, they are likely seldomly unused, vectors of 16- and 32-bit types are important.
Move create_scope_map to rustc_codegen_ssa. This resolves an old FIXME and allows to deduplicate code between LLVM and GCC.
The operation is a no-op, so we skip it.
remove LLVM `va_end` calls tracking issue: rust-lang/rust#44930 The operation is a no-op, so we skip it.
When emitting a `memcpy` for a scalable vector, the size computed by rustc (`num_vectors * element_count * element_ty`), since rust-lang/rust#157915, needs to be multiplied by `vscale`.
And while I'm here, improve the tests to check that the unaligned ones are actually unaligned, since `unaligned_volatile_load::<u8>` doesn't actually test anything.
Clippy subtree update r? Manishearth
cg_LLVM: Stop needing an alloca for volatile loads This ended up also being reimplementing it to not use `load` of the `llvm_type`, since without doing that everything blew up horribly. cc the zulip conversation [#t-opsem > Defining volatile splitting @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Defining.20volatile.20splitting/near/597451615). And while I'm here, improve the tests to check that the unaligned ones are actually unaligned, since `unaligned_volatile_load::<u8>` doesn't actually test anything. r? @nikic cc @RalfJung MCP tracking issue rust-lang/rust#153250
Collaborator
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
15 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.