rust/compiler/rustc_ty_utils
bors a2a1206811 Auto merge of #131211 - bjorn3:rust_abi_follow_c_rules, r=nikic,jieyouxu
Return values larger than 2 registers using a return area pointer

LLVM and Cranelift disagree about how to return values that don't fit in the registers designated for return values. LLVM will force the entire return value to be passed by return area pointer, while Cranelift will look at each IR level return value independently and decide to pass it in a register or not, which would result in the return value being passed partially in registers and partially through a return area pointer.

While Cranelift may need to be fixed as the LLVM behavior is generally more correct with respect to the surface language, forcing this behavior in rustc itself makes it easier for other backends to conform to the Rust ABI and for the C ABI rustc already handles this behavior anyway.

In addition LLVM's decision to pass the return value in registers or using a return area pointer depends on how exactly the return type is lowered to an LLVM IR type. For example `Option<u128>` can be lowered as `{ i128, i128 }` in which case the x86_64 backend would use a return area pointer, or it could be passed as `{ i32, i128 }` in which case the x86_64 backend would pass it in registers by taking advantage of an LLVM ABI extension that allows using 3 registers for the x86_64 sysv call conv rather than the officially specified 2 registers.

This adjustment is only necessary for the Rust ABI as for other ABI's the calling convention implementations in rustc_target already ensure any return value which doesn't fit in the available amount of return registers is passed in the right way for the current target.

Helps with https://github.com/rust-lang/rustc_codegen_cranelift/issues/1525
cc https://github.com/bytecodealliance/wasmtime/issues/9250
2024-10-19 14:21:46 +00:00
..
src Auto merge of #131211 - bjorn3:rust_abi_follow_c_rules, r=nikic,jieyouxu 2024-10-19 14:21:46 +00:00
Cargo.toml compiler: Factor rustc_target::abi::* out of ty_utils 2024-10-08 18:24:38 -07:00
messages.ftl s/generator/coroutine/ 2023-10-20 21:14:01 +00:00