-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nested tuple leads to worse code #63244
Comments
Notably this effects the type pub type Oink = (u128, ());
pub fn oink(a: Oink, b: Oink) -> Oink {
(a.0 + b.0, ())
} ASM:
(I couldn't think of a farm animal sound that rhymes with "baz") |
Moo, moo, brown cow, have you milk for me? |
Web repro: https://rust.godbolt.org/z/3lLlZF This looks like a Rust ABI thing -- %Moo = type { [0 x i64], { [0 x i64], i128, [0 x i8], {}, [0 x i8] }, [0 x i64] }
define void @_ZN7example3moo17hef8326368864ce30E(%Moo* noalias nocapture sret dereferenceable(16), %Moo* noalias nocapture readonly dereferenceable(16) %a, %Moo* noalias nocapture readonly dereferenceable(16) %b) unnamed_addr #0 {
define i128 @_ZN7example3baa17h7849d3e5f09843b9E(i128 %a, i128 %b) unnamed_addr #1 { The ASM differences are uninteresting -- they're just from the parameters (and return value) being passed as pointers vs being passed by value. |
Would it be possible for the Rust ABI to make tuples behave as repr transparent? As it is, a tuple with an element and a ZST marker would not be zero-cost. |
For
cargo asm
givesand
The text was updated successfully, but these errors were encountered: