mem::zeroed unrolls hilariously enormous loops

[richo]

test program:

extern crate core;

use core::mem;

const SIZE: usize = 512 * 1024 * 1024;

fn main() {
    let memory: Box<[u8; SIZE]> = unsafe { Box::new(mem::zeroed()) };
}

hangs for longer than I was willing to let it run. A smaller testcase, replacing 512 with 1 fails an assertion: Assertion failed: ((!Node || ResNo < Node->getNumValues()) && "Invalid result number for the given node!"), function SDValue, file /Users/richo/code/ext/rust/src/llvm/include/llvm/CodeGen/SelectionDAGNodes.h, line 899.

Finally, in the original program I discovered this bug in generated this:

__ZN3mem6zeroed21h15945040308467491263E:
0000000000000890        cmpq    %gs:0x330, %rsp
0000000000000899        ja      0x8b5
000000000000089b        movabsq $0x8, %r10
00000000000008a5        movabsq $0x0, %r11
00000000000008af        callq   0x8b4
00000000000008b4        retq
00000000000008b5        pushq   %rbp
00000000000008b6        movq    %rsp, %rbp
00000000000008b9        movq    %rdi, %rax
00000000000008bc        movb    $0x0, 0x46(%rdi)
00000000000008c0        movb    $0x0, 0x45(%rdi)
00000000000008c4        movb    $0x0, 0x44(%rdi)
00000000000008c8        movb    $0x0, 0x43(%rdi)
00000000000008cc        movb    $0x0, 0x42(%rdi)
00000000000008d0        movb    $0x0, 0x41(%rdi)
00000000000008d4        movb    $0x0, 0x40(%rdi)
00000000000008d8        movb    $0x0, 0x3f(%rdi)
00000000000008dc        movb    $0x0, 0x3e(%rdi)
00000000000008e0        movb    $0x0, 0x3d(%rdi)
00000000000008e4        movb    $0x0, 0x3c(%rdi)
00000000000008e8        movb    $0x0, 0x3b(%rdi)
00000000000008ec        movb    $0x0, 0x3a(%rdi)
00000000000008f0        movb    $0x0, 0x39(%rdi)
00000000000008f4        movb    $0x0, 0x38(%rdi)
00000000000008f8        movb    $0x0, 0x37(%rdi)
00000000000008fc        movb    $0x0, 0x36(%rdi)
0000000000000900        movb    $0x0, 0x35(%rdi)
0000000000000904        movb    $0x0, 0x34(%rdi)
0000000000000908        movb    $0x0, 0x33(%rdi)
000000000000090c        movb    $0x0, 0x32(%rdi)
0000000000000910        movb    $0x0, 0x31(%rdi)
0000000000000914        movb    $0x0, 0x30(%rdi)
0000000000000918        movb    $0x0, 0x2f(%rdi)
000000000000091c        movb    $0x0, 0x2e(%rdi)
0000000000000920        movb    $0x0, 0x2d(%rdi)
0000000000000924        movb    $0x0, 0x2c(%rdi)
0000000000000928        movb    $0x0, 0x2b(%rdi)
000000000000092c        movb    $0x0, 0x2a(%rdi)
0000000000000930        movb    $0x0, 0x29(%rdi)
0000000000000934        movb    $0x0, 0x28(%rdi)
0000000000000938        movb    $0x0, 0x27(%rdi)
000000000000093c        movb    $0x0, 0x26(%rdi)
0000000000000940        movb    $0x0, 0x25(%rdi)
0000000000000944        movb    $0x0, 0x24(%rdi)
0000000000000948        movb    $0x0, 0x23(%rdi)
000000000000094c        movb    $0x0, 0x22(%rdi)
0000000000000950        movb    $0x0, 0x21(%rdi)
0000000000000954        movb    $0x0, 0x20(%rdi)
0000000000000958        movb    $0x0, 0x1f(%rdi)
(Continues for several megabytes)

[nagisa]

A smaller testcase, replacing 512 with 1 fails an assertion: Assertion failed: ((!Node || ResNo < Node->getNumValues()) && "Invalid result number for the given node!"), function SDValue, file /Users/richo/code/ext/rust/src/llvm/include/llvm/CodeGen/SelectionDAGNodes.h, line 899.

Can only reproduce when built without optimisations (i.e. -O). I don’t see the long list of movs in the assembly generated before the error occurs.

If compile with optimisations on, though,…

time: 0.001     llvm function passes
  time: 26.826  llvm module passes
  time: 0.010   codegen passes
  time: 0.000   codegen passes
time: 28.111    LLVM passes
  time: 0.215   running linker

The assembly I get back from the LLVM does not contain any such mov trains as reported above either (in both cases a call to memset@PLT appears), though the rustc/LLVM asks the system for 40% of my 8GB RAM.

This is with 1 * 1024 * 1024.

LLVM bug?

[Aatch]

mem::zeroed forwards to an intrinsic init that compiles down to a zeroinitializer value in LLVM, so it's technically a bug in LLVM that causes this. Optimisations almost always result in a memset to zero with large values, but apparently LLVM will output a series of moves for a zeroinitializer value.

We could probably detect larger values and output a memset of zeroes ourselves to avoid this to some extend.

[Aatch]

Hah, in the process of fixing this, I encountered a comment warning about exactly this phenomenom. It's a known issue in LLVM, generating long sequences of movs for large types. Hopefully I'll have a fix up soon.

[richo]

Plausible. This was a tracking issue for my own use as much as anything
else. I'll follow up next week.

On Friday, January 16, 2015, James Miller notifications@github.com wrote:

Hah, in the process of fixing this, I encountered a comment warning about
exactly this phenomenom. It's a known issue in LLVM, generating long
sequences of movs for large types. Hopefully I'll have a fix up soon.

—
Reply to this email directly or view it on GitHub
#21264 (comment).