Compiler runs forever at opt-level=3

[jcriddle4]

When I switch from opt-level=1 to opt-level=3 my program goes from compiling instantly to rustc running at 100% cpu and never finishing(many hours....).

The code can be found at:
https://github.com/jcriddle4/rust_cry

[hanna-kruppe]

Running with -print-before-all, the last output I get is

*** IR Dump Before Canonicalize natural loops ***

; Function Attrs: uwtable
define internal fastcc void @_ZN5hello6cry12813init_r128_ecb17hbce393027723a3edE(...) ...

Although for some reason the code formatting is all messed up.

[Mark-Simulacrum]

I cannot reproduce on 64-bit Ubuntu with nightly rustc (rustc 1.20.0-nightly (15aa15b03 2017-07-21). However, I can reproduce on both beta and stable. Probably something we've fixed recently.... not sure what it could be though.

[Mark-Simulacrum]

Or, wait, no I'm just not looking at the right crate being built.. ignore me. Presumably some case of bad LLVM IR generation...

[jcriddle4]

Mark what part of your prior comment should be ignored? If the comment is wrong is it possible to edit it?

[Mark-Simulacrum]

All of it. I can reliably reproduce on both platforms.

[jcriddle4]

I have installed rustc 1.20.0-nightly (8d22af8 2017-07-22) and confirmed that it is still broken.

[jcriddle4]

The issue was narrowed down. In file cry128.rs and functions init_r128 and init_r128_ecb It looks like the more calls to inner function whack_ar(....) the massively slower and slower the compiler seems to run.

[jcriddle4]

Smaller version of project that recreates the issue: https://github.com/jcriddle4/rust_small

[Mark-Simulacrum]

Eliminated the dependency on byteorder. cc @arielb1 -- this is a case where LLVM gets stuck

use std::mem;

fn read_u32(buf: &[u8]) -> u32 {
    let mut data: u32 = 0;
    unsafe {
        std::ptr::copy_nonoverlapping(
            buf.as_ptr(),
            &mut data as *mut u32 as *mut u8,
            4
        );
    }
    data.to_le()
}

const EXPECTED_SIZE: usize = 90000;

fn slow_stuff() {
    let mut x: [u32; 256];
    let mut ee: [u8; EXPECTED_SIZE];

    unsafe {
        x = mem::uninitialized();
        ee = mem::uninitialized();
    }

    let mut ptr: usize = 0;
    fn whack_ar(a: &mut [u32; 256], ptr: &mut usize, ee: &mut [u8; EXPECTED_SIZE]) {
        for elem in a.iter_mut() {
            *elem = read_u32(&mut ee[*ptr..(*ptr+4)]);
            *ptr = *ptr + 4;
        }
    }

    whack_ar(&mut x, &mut ptr, &mut ee);
    whack_ar(&mut x, &mut ptr, &mut ee);
    whack_ar(&mut x, &mut ptr, &mut ee);
    whack_ar(&mut x, &mut ptr, &mut ee);
    whack_ar(&mut x, &mut ptr, &mut ee);
    whack_ar(&mut x, &mut ptr, &mut ee);
    whack_ar(&mut x, &mut ptr, &mut ee);
    whack_ar(&mut x, &mut ptr, &mut ee);
    whack_ar(&mut x, &mut ptr, &mut ee);
    whack_ar(&mut x, &mut ptr, &mut ee);
    whack_ar(&mut x, &mut ptr,&mut ee);
    whack_ar(&mut x, &mut ptr,&mut ee);
    whack_ar(&mut x, &mut ptr,&mut ee);
    whack_ar(&mut x, &mut ptr,&mut ee);
    whack_ar(&mut x, &mut ptr,&mut ee);
    whack_ar(&mut x, &mut ptr,&mut ee);
    whack_ar(&mut x, &mut ptr,&mut ee);
    whack_ar(&mut x, &mut ptr,&mut ee);
    whack_ar(&mut x, &mut ptr,&mut ee);
    whack_ar(&mut x, &mut ptr,&mut ee);
    whack_ar(&mut x, &mut ptr,&mut ee);
    whack_ar(&mut x, &mut ptr,&mut ee);
    whack_ar(&mut x, &mut ptr,&mut ee);
    whack_ar(&mut x, &mut ptr,&mut ee);
    whack_ar(&mut x, &mut ptr,&mut ee);
    whack_ar(&mut x, &mut ptr,&mut ee);
}

fn main() {
    slow_stuff();
}

[alexcrichton]

I've submitted an usptream LLVM bug based on @Mark-Simulacrum's test case reduced with bugpoint

[alexcrichton]

Correction, it's fixed in LLVM 5.0.0, now blocked on #43370