rust/compiler/rustc_codegen_ssa/src/mir, branch beta

Rollup merge of #144549 - folkertdev:va-arg-arm, r=saethlin

2025-09-12T10:02:10+00:00

match clang's `va_arg` assembly on arm targets tracking issue: https://github.com/rust-lang/rust/issues/44930 For this example ```rust #![feature(c_variadic)] #[unsafe(no_mangle)] unsafe extern "C" fn variadic(a: f64, mut args: ...) -> f64 { let b = args.arg::(); let c = args.arg::(); a + b + c } ``` We currently generate (via llvm): ```asm variadic: sub sp, sp, #12 stmib sp, {r2, r3} vmov d0, r0, r1 add r0, sp, #4 vldr d1, [sp, #4] add r0, r0, #15 bic r0, r0, #7 vadd.f64 d0, d0, d1 add r1, r0, #8 str r1, [sp] vldr d1, [r0] vadd.f64 d0, d0, d1 vmov r0, r1, d0 add sp, sp, #12 bx lr ``` LLVM is not doing a good job. In fact, it's well-known that LLVM's implementation of `va_arg` is kind of bad, and we implement it ourselves (based on clang) for many targets already. For arm, our own `emit_ptr_va_arg` saves 3 instructions. Next, it turns out it's important for LLVM to explicitly start and end the lifetime of the `va_list`. In https://github.com/rust-lang/rust/pull/146059 I already end the lifetime, but when looking at this again, I noticed that it is important to also start it, see https://godbolt.org/z/EGqvKTTsK: failing to explicitly start the lifetime uses an extra register. So, the combination of `emit_ptr_va_arg` with starting/ending the lifetime makes rustc emit exactly the instructions that clang generates:: ```asm variadic: sub sp, sp, #12 stmib sp, {r2, r3} vmov d16, r0, r1 vldr d17, [sp, #4] vadd.f64 d16, d16, d17 vldr d17, [sp, #12] vadd.f64 d16, d16, d17 vmov r0, r1, d16 add sp, sp, #12 bx lr ``` The arguments to `emit_ptr_va_arg` are based on [the clang implementation](https://github.com/llvm/llvm-project/blob/03dc2a41f3d9a500e47b513de5c5008c06860d65/clang/lib/CodeGen/Targets/ARM.cpp#L798-L844). r? ``@workingjubilee`` (I can re-roll if your queue is too full, but you do seem like the right person here) try-job: armhf-gnu

Use `Itertools::all_equal_value()` where applicable

2025-09-05T18:43:43+00:00

explicitly start `va_list` lifetime

2025-09-02T22:19:18+00:00

explicitly end `va_list` lifetime

2025-08-31T14:07:28+00:00

Rollup merge of #144865 - WaffleLapkin:track-tail, r=lqd

2025-08-15T06:16:31+00:00

Fix tail calls to `#[track_caller]` functions We want `#[track_caller]` to be semver independent, i.e. it should not be a breaking change to add or remove it. Since it changes ABI of a function (adding an additional argument) we have to be careful to preserve this property when adding tail calls. The only way to achieve this that I can see is: - we forbid tail calls in functions which are marked with `#[track_caller]` (already implemented) - tail-calling a `#[track_caller]` marked function downgrades the tail-call to a normal call (or equivalently tail-calls the shim made by fn def to fn ptr cast) (this pr) Ideally the downgrade would be performed by a MIR pass, but that requires post mono MIR opts (cc ```@saethlin,``` rust-lang/rust#131650). For now I've changed code in cg_ssa to accomodate this behaviour (+ added a hack to mono collector so that the shim is actually generated) Additionally I added a lint, although I don't think it's strictly necessary. Alternative to rust-lang/rust#144762 (and thus closes rust-lang/rust#144762) Fixes https://github.com/rust-lang/rust/issues/144755

drive-by: fix typo

2025-08-14T19:23:49+00:00

Port the `#[linkage]` attribute to the new attribute system

2025-08-13T19:01:37+00:00

fix tail calls to `#[track_caller]` functions

2025-08-13T00:26:52+00:00

Rollup merge of #144192 - RalfJung:atomicrmw-ptr, r=nikic

2025-08-08T19:22:44+00:00

atomicrmw on pointers: move integer-pointer cast hacks into backend Conceptually, we want to have atomic operations on pointers of the form `fn atomic_add(ptr: *mut T, offset: usize, ...)`. However, LLVM does not directly support such operations (https://github.com/llvm/llvm-project/issues/120837), so we have to cast the `offset` to a pointer somewhere. This PR moves that hack into the LLVM backend, so that the standard library, intrinsic, and Miri all work with the conceptual operation we actually want. Hopefully, one day LLVM will gain a way to represent these operations without integer-pointer casts, and then the hack will disappear entirely. Cc ```@nikic``` -- this is the best we can do right now, right? Fixes https://github.com/rust-lang/rust/issues/134617

Rollup merge of #144999 - Zalathar:remove-mcdc, r=oli-obk

2025-08-08T02:52:54+00:00

coverage: Remove all unstable support for MC/DC instrumentation Preliminary support for a partial implementation of “Modified Condition/Decision Coverage” instrumentation was added behind the unstable flag `-Zcoverage-options=mcdc` in 2024. These are the most substantial PRs involved: - rust-lang/rust#123409 - rust-lang/rust#126733 At the time, I accepted these PRs with relatively modest scrutiny, because I did not want to stand in the way of independent work on MC/DC instrumentation. My hope was that ongoing work by interested contributors would lead to the code becoming clearer and more maintainable over time. --- However, that MC/DC code has proven itself to be a major burden on overall maintenance of coverage instrumentation, and a major obstacle to other planned improvements, such as internal changes needed for proper support of macro expansion regions. I have also become reluctant to accept any further MC/DC-related changes that would increase this burden. That tension has resulted in an unhappy impasse. On one hand, the present MC/DC implementation is not yet complete, and shows little sign of being complete at an acceptable level of code quality in the foreseeable future. On the other hand, the continued existence of this partial MC/DC implementation is imposing serious maintenance burdens on every other aspect of coverage instrumentation, and is preventing some of the very improvements that would make it easier to accept expanded MC/DC support in the future. While I know this will be disappointing to some, I think the healthy way forward is accept that I made the wrong call in accepting the current implementation, and to remove it entirely from the compiler.