cg_LLVM: Stop needing an alloca for volatile loads by scottmcm · Pull Request #157127 · rust-lang/rust

scottmcm · 2026-05-29T21:20:12Z

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 @ 💬.

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 #153250

rustbot · 2026-06-03T05:18:09Z

The GCC codegen subtree was changed

cc @antoyo, @GuillaumeGomez

scottmcm · 2026-06-06T20:51:09Z


-    fn volatile_load(&mut self, ty: Type<'gcc>, ptr: RValue<'gcc>) -> RValue<'gcc> {
+    fn volatile_load(&mut self, ty: Type<'gcc>, ptr: RValue<'gcc>, _: Align) -> RValue<'gcc> {
+        // FIXME(antoyo): set alignment.


annot: it wasn't obvious to me how to get this to work -- maybe that's why it was already a FIXME -- so I ended up just moving the FIXME from the volatile_load intrinsic to the volatile_load builder method, which doesn't make anything worse at least.

View changes since the review

scottmcm · 2026-06-18T20:08:14Z

Sorry for taking a bazillion iterations on this. CI is happy now, so I think this is finally
@rustbot ready

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.

rustbot · 2026-06-26T04:04:15Z

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.

nikic · 2026-06-26T07:57:42Z

@bors r+

I would not be surprised if this breaks someones embedded code because they expected a volatile load of a struct to be split in some specific way. I guess we'll find out...

rust-bors · 2026-06-26T07:57:45Z

📌 Commit 9b188dd has been approved by nikic

It is now in the queue for this repository.

🌲 The tree is currently closed for pull requests below priority 1. This pull request will be tested once the tree is reopened.

@nikic

…ve, r=nikic 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#153250

…uwer Rollup of 4 pull requests Successful merges: - #157127 (cg_LLVM: Stop needing an alloca for volatile loads) - #158244 (Attribute docs `deprecated` , `warn`, `allow`, `cfg`, `deny`, and `forbid` ) - #158399 (std: truncate thread names on NetBSD) - #158430 (Guard clone suggestion against empty obligation errors)

@nikic

…ve, r=nikic 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#153250

…uwer Rollup of 6 pull requests Successful merges: - #158360 (Various borrowck cleanups and param_env/opaque_types_defined_by query simplifications for typeck children) - #157127 (cg_LLVM: Stop needing an alloca for volatile loads) - #158244 (Attribute docs `deprecated` , `warn`, `allow`, `cfg`, `deny`, and `forbid` ) - #158355 (Fixup the refactoring errors in #156246) - #158399 (std: truncate thread names on NetBSD) - #158430 (Guard clone suggestion against empty obligation errors)

@nikic

…ve, r=nikic 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#153250

…uwer Rollup of 7 pull requests Successful merges: - #158360 (Various borrowck cleanups and param_env/opaque_types_defined_by query simplifications for typeck children) - #157127 (cg_LLVM: Stop needing an alloca for volatile loads) - #158244 (Attribute docs `deprecated` , `warn`, `allow`, `cfg`, `deny`, and `forbid` ) - #158355 (Fixup the refactoring errors in #156246) - #158361 (Move `check_ffi_pure` into the attribute parser) - #158399 (std: truncate thread names on NetBSD) - #158430 (Guard clone suggestion against empty obligation errors)

rustbot assigned nikic May 29, 2026

scottmcm added the A-codegen Area: Code generation label May 29, 2026

bjorn3 reviewed May 30, 2026

View reviewed changes

Comment thread compiler/rustc_codegen_llvm/src/intrinsic.rs Outdated

RalfJung reviewed May 31, 2026

View reviewed changes

Comment thread compiler/rustc_codegen_llvm/src/intrinsic.rs Outdated

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 31, 2026

scottmcm force-pushed the tweak-layout-of-alternative branch from ff8746f to 9ff8e99 Compare June 3, 2026 05:18