-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Nested tuple leads to worse code #63244
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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: