make `pad_i32` of `PassMode::cast` an integer by folkertdev · Pull Request #160132 · rust-lang/rust

folkertdev · 2026-07-29T09:12:59Z

so that we can specify more than one i32 of padding. This PR only adds the functionality but does not yet use it: there should be no functional changes.

This is needed for the ABI of Complex<{ float }> on 32-bit powerpc. Other mechanisms, e.g. using PassMode::prefixed don't appear to work.

More discussion is in #t-compiler/help > power complex abi.

folkertdev · 2026-07-29T12:05:30Z

+    fn reg_backend_type(&self, ty: &Reg) -> Type<'gcc> {
+        ty.gcc_type(self)
    }


This is extrapolating from the LLVM implementation, it seems to work fine, cc @antoyo if there is something I'm missing.

View changes since the review

This should be fine.

folkertdev · 2026-07-29T12:07:07Z

+    /// `pad_i32` indicates how many `Reg::i32()` dummy arguments are emitted before the real
+    /// argument.
+    Cast { pad_i32: u8, cast: Box<CastTarget> },


I'm not sure about the name, but can't really think of anything obviously better but also somewhat short.

View changes since the review

folkertdev · 2026-07-29T12:07:40Z

r? @bjorn3
cc @workingjubilee

rustbot · 2026-07-29T12:07:51Z

rustc_codegen_cranelift is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_cranelift instead.

cc @bjorn3

This PR changes rustc_public

cc @oli-obk, @celinval, @ouz-a, @makai410

rustc_codegen_gcc is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_gcc instead.

cc @antoyo, @GuillaumeGomez

antoyo · 2026-08-03T22:13:01Z

FYI, there's some issue with cg_gcc and we're about to revert the last sync.

so that we can specify more than one i32 of padding.

rustbot · 2026-08-04T07:57:59Z

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.

bjorn3 · 2026-08-04T15:03:04Z

This is needed for the ABI of Complex<{ float }> on 32-bit powerpc.

What exactly is the ABI for that type that it needs more than 1 i32 padding?

folkertdev · 2026-08-04T15:07:44Z

On powerpc (a 32-bit target), when a Complex<i64> (say) does not fit in the remaining registers, it is moved to the stack (i.e., it is not split between registers and stack) but crucially the remaining registers are consumed. so if there is another i32argument after theComplex` then that must also be passed via the stack. So depending on the number remaining argument registers, you may need to consume up to 3 registers.

bjorn3 · 2026-08-04T15:11:10Z

On powerpc (a 32-bit target), when a Complex (say) does not fit in the remaining registers, it is moved to the stack (i.e., it is not split between registers and stack) but crucially the remaining registers are consumed.

As I understand it, PassMode::Cast should already consume all remaining registers if it is forced to the stack. Is that not the case?

folkertdev · 2026-08-04T15:37:49Z

Well so in practice a Complex<i64> or Complex<f64> is actually passed as a [4 x i32] LLVM type, which gives the correct register alignment of 4 (it's weird, but Complex<f32> has a register alignment of 8. this is explicitly documented in GCC) and ensures the value is passed in GPRs, not FPRs.

A [4 x i32] gets split into 4 distinct i32 arguments by LLVM, and so if we don't explicitly occupy the remaining GPR registers then the value is in fact split between registers and stack.

folkertdev · 2026-08-04T17:07:51Z

Something that sort of works is using a simd type, because it does not get split. But, it (correctly) warns about missing target features, and scheme probably fails when there are actually vector registers available.

So, yeah, I think this change is needed to support that ABI. it's still pretty limited, Clang allows you to specify a whole custom type for padding.