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? # 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

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
# for free to join this conversation on GitHub. Already have an account? # 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