"Flags mismatch!" assertion on LLVM 5.0 with MIPS

[alexcrichton]

Bugzilla Link	33978
Resolution	FIXED
Resolved on	Aug 03, 2017 17:47
Version	5.0
OS	Windows NT
Blocks	#33196
CC	@zmodem

Extended Description

In updating rust-lang/rust to LLVM 5.0 we've discovered what appears to be a code generator assertion on MIPS targets. We've used bugpoint to minimize the failing test case to:

target triple = "mips-unknown-linux-gnu"

define void @​foo() {
start:
%a = alloca i32
%b = alloca [22 x i8], align 2
%c = bitcast i32* %a to i8*
%d = getelementptr inbounds [22 x i8], [22 x i8]* %b, i32 0, i32 2
call void @​llvm.memcpy.p0i8.p0i8.i32(i8* nonnull %c, i8* %d, i32 20, i32 2, i1 false)
%e = getelementptr inbounds [22 x i8], [22 x i8]* %b, i32 0, i32 6
call void @​llvm.memcpy.p0i8.p0i8.i32(i8* undef, i8* %e, i32 12, i32 2, i1 false)
ret void
}

declare void @​llvm.memcpy.p0i8.p0i8.i32(i8*, i8*, i32, i32, i1)

If this is exected with llc foo.ll -filetype=obj -o foo.o then it'll crash with:

llc: /checkout/src/llvm/lib/CodeGen/MachineInstr.cpp:649: void llvm::MachineMemOperand::refineAlignment(const llvm::MachineMemOperand*): Assertion `MMO->getFlags() == getFlags() && "Flags mismatch!"' failed.
#​0 0x0000000001bbfb8a (llc+0x1bbfb8a)
#​1 0x0000000001bbd8fe (llc+0x1bbd8fe)
#​2 0x0000000001bbda72 (llc+0x1bbda72)
#​3 0x00007f1262aed390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
#​4 0x00007f1261ca2428 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35428)
#​5 0x00007f1261ca402a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3702a)
#​6 0x00007f1261c9abd7 (/lib/x86_64-linux-gnu/libc.so.6+0x2dbd7)
#​7 0x00007f1261c9ac82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82)
#​8 0x0000000001394e90 (llc+0x1394e90)
#​9 0x0000000001a58be7 (llc+0x1a58be7)
#​10 0x0000000000c7bace (llc+0xc7bace)
#​11 0x0000000000c816d7 (llc+0xc816d7)
#​12 0x0000000000cb8175 (llc+0xcb8175)
#​13 0x0000000000cc7875 (llc+0xcc7875)
#​14 0x00000000019c9f38 (llc+0x19c9f38)
#​15 0x00000000019d014e (llc+0x19d014e)
#​16 0x00000000019d472c (llc+0x19d472c)
#​17 0x0000000001a8659a (llc+0x1a8659a)
#​18 0x0000000001a8c8b9 (llc+0x1a8c8b9)
#​19 0x0000000001a8e869 (llc+0x1a8e869)
#​20 0x0000000000c7a44a (llc+0xc7a44a)
#​21 0x000000000138ee85 (llc+0x138ee85)
#​22 0x00000000016966c3 (llc+0x16966c3)
#​23 0x000000000169678c (llc+0x169678c)
#​24 0x000000000169622d (llc+0x169622d)
#​25 0x00000000006eed03 (llc+0x6eed03)
#​26 0x0000000000681e1c (llc+0x681e1c)
#​27 0x00007f1261c8d830 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20830)
#​28 0x00000000006e1b09 (llc+0x6e1b09)
Stack dump:
0. Program arguments: llc bugpoint-reduced-simplified.ll -filetype=obj -o foo.o

1. Running pass 'Function Pass Manager' on module 'bugpoint-reduced-simplified.ll'.
2. Running pass 'MIPS DAG->DAG Pattern Instruction Selection' on function '@foo'

[llvmbot]

Taking a look at this.

[llvmbot]

We're tripping up on the undef operand to memcpy. How did rust's compiler manage to generate this?

call void @​llvm.memcpy.p0i8.p0i8.i32(i8* undef, i8* %e, i32 12, i32 2, i1 false)

This is a write of 12 bytes to some arbitrary location.

[alexcrichton]

Heh indeed! AFAIK rustc itself wouldn't generate that but maybe that was introduced by bugpoint during minimization? I can try to get an example that fails and may otherwise plausibly compile if that'd help. I could also help provide the original IR if that'd be easier!

[llvmbot]

If you can post the original IR / and/or check it for the usage of memcpy with undef as a source/destination.

If the original rust code was from unsafe rust, that's somewhat expected due to undefined behaviour. If it was from safe rust code, then you may have a bug on your hands like us.

Thanks,
Simon

[alexcrichton]

Sure yeah! The original IR is here: https://gist.github.com/alexcrichton/96d748e61de559d8a8eacbfd1c915565

That fails as well with llc -filetype=obj -O2 ./foo.ll -o foo.o

I noticed though that this IR (w/o undef) has the same assertion failure as the original IR:

target triple = "mips-unknown-linux-gnu"

define void @​foo(i8*) {
start:
%a = alloca [22 x i8]
%b = alloca [22 x i8]
%c = bitcast [22 x i8]* %a to i8*
%d = getelementptr inbounds [22 x i8], [22 x i8]* %b, i32 0, i32 2
call void @​llvm.memcpy.p0i8.p0i8.i32(i8* %c, i8* %d, i32 20, i32 1, i1 false)
%e = getelementptr inbounds [22 x i8], [22 x i8]* %b, i32 0, i32 6
call void @​llvm.memcpy.p0i8.p0i8.i32(i8* %0, i8* %e, i32 12, i32 1, i1 false)
ret void
}

declare void @​llvm.memcpy.p0i8.p0i8.i32(i8*, i8*, i32, i32, i1)

[llvmbot]

r309561.

[llvmbot]

Argh, closed wrong bug.

[llvmbot]

r309930.

Hans, could you merge that?

Thanks

[zmodem]

r309930.

Hans, could you merge that?

Thanks

r309956. Thanks!

[alexcrichton]

Thanks so much for the investigation and the fix Simon!