Skip to content

Statically sized vectors on the stack result in atrocious code gen at --opt-level=0 #4694

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

Closed
alexrp opened this issue Jan 30, 2013 · 2 comments
Labels
A-codegen Area: Code generation I-slow Issue: Problems and improvements with respect to performance of generated code.

Comments

@alexrp
Copy link

alexrp commented Jan 30, 2013

A program like this:

fn main() -> () {
    let x = [0, .. 1024];
    io::println(fmt!("%?", x));
}

Results in code like (--opt-level=0):

4009b8:       48 c7 85 00 e0 ff ff    mov    QWORD PTR [rbp-0x2000],0x0
4009bf:       00 00 00 00 
4009c3:       48 c7 85 08 e0 ff ff    mov    QWORD PTR [rbp-0x1ff8],0x0
4009ca:       00 00 00 00 
4009ce:       48 c7 85 10 e0 ff ff    mov    QWORD PTR [rbp-0x1ff0],0x0
4009d5:       00 00 00 00 
4009d9:       48 c7 85 18 e0 ff ff    mov    QWORD PTR [rbp-0x1fe8],0x0
4009e0:       00 00 00 00 
4009e4:       48 c7 85 20 e0 ff ff    mov    QWORD PTR [rbp-0x1fe0],0x0
4009eb:       00 00 00 00 
4009ef:       48 c7 85 28 e0 ff ff    mov    QWORD PTR [rbp-0x1fd8],0x0
4009f6:       00 00 00 00 
; and so on...

But with--opt-level=3:

40308b:       4c 8d b5 68 df ff ff    lea    r14,[rbp-0x2098]
403092:       4c 89 f7                mov    rdi,r14
403095:       31 f6                   xor    esi,esi
403097:       ba 00 20 00 00          mov    edx,0x2000
40309c:       e8 2f fa ff ff          call   402ad0 <memset@plt>
; ...

Which is what we'd expect.

I know it probably doesn't matter /too/ much how bad the code gen is with no optimization on, but generating a load for every static vector element could result in some serious code explosion.

@huonw
Copy link
Member

huonw commented Mar 24, 2013

This still occurs, and, if the contents (i.e. 0 in this case) is changed to a value that can't be memset (x = [1, ..1024]) then even --opt-level=3 generates the horrible code:

000010DF  48C78578DFFFFF01  mov qword [rbp-0x2088],0x1
         -000000
000010EA  48C78580DFFFFF01  mov qword [rbp-0x2080],0x1
         -000000
000010F5  48C78588DFFFFF01  mov qword [rbp-0x2078],0x1
         -000000
00001100  48C78590DFFFFF01  mov qword [rbp-0x2070],0x1
         -000000
0000110B  48C78598DFFFFF01  mov qword [rbp-0x2068],0x1
         -000000
00001116  48C785A0DFFFFF01  mov qword [rbp-0x2060],0x1
         -000000
00001121  48C785A8DFFFFF01  mov qword [rbp-0x2058],0x1
         -000000
0000112C  48C785B0DFFFFF01  mov qword [rbp-0x2050],0x1
         -000000
; etc.

I'm going to attempt to fix this by getting rustc to generate a loop, instead of individual mov instructions, which llvm can hopefully unroll/optimise as appropriate.

@luqmana
Copy link
Member

luqmana commented Apr 25, 2013

Fixed with #5524.

@luqmana luqmana closed this as completed Apr 25, 2013
bors added a commit to rust-lang-ci/rust that referenced this issue Oct 24, 2020
… r=ebroto

Identical arguments on assert macro family

Lint when identical args are used on `assert_eq!`, `debug_assert_eq!`, `assert_ne!` and `debug_assert_ne!` macros.

Added to the lint `eq_op`.

Common functions added to `utils/higher.rs`

Fixes: rust-lang#3574
Fixes: rust-lang#4694

changelog: Lint on identical args when calling `assert_eq!`, `debug_assert_eq!`, `assert_ne!` and `debug_assert_ne!` macros
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation I-slow Issue: Problems and improvements with respect to performance of generated code.
Projects
None yet
Development

No branches or pull requests

3 participants