miscompiled extractelement instruction

[llvmbot]

Bugzilla Link	10747
Resolution	FIXED
Resolved on	Dec 26, 2011 16:49
Version	trunk
OS	Linux
Reporter	LLVM Bugzilla Contributor
CC	@efriedma-quic

Extended Description

Testcase:
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

define i32 @​main() {
BB0:
%0 = alloca <2 x i64>, align 16
%1 = getelementptr <2 x i64>* %0, i32 0, i32 1
store i64 6, i64* %1
%2 = getelementptr inbounds <2 x i64>* %0, i32 0, i32 0
store i64 1, i64* %2
%3 = ptrtoint <2 x i64>* %0 to i64
%4 = inttoptr i64 %3 to <2 x i64>*
%5 = load <2 x i64>* %4, align 1
store i64 4, i64* %1
store i64 3, i64* %2
%6 = extractelement <2 x i64> %5, i32 1
%7 = trunc i64 %6 to i32
ret i32 %7
}

Compile using:
llvm-as -o temp.bc bug.ll && llc -march=x86-64 -o temp.s temp.bc && gcc temp.s && ./a.out

This should exit with exit code 6, but it exits with code 4.

This is with LLVM HEAD on x86-64.

This seems to be caused by revision 131183, i.e.:

Author: Nadav Rotem nadav.rotem@intel.com
Date: Wed May 11 14:40:50 2011 +0000

Fixes a bug in the DAGCombiner.  LoadSDNodes have two values (data, chain).
If there is a store after the load node, then there is a chain, which means
that there is another user. Thus, asking hasOneUser would fail. Instead we
ask hasNUsesOfValue on the 'data' value.

[efriedma-quic]

Yes... and the cause is pretty straightforward: the transformation in question doesn't handle the case where the chain has uses correctly.

[efriedma-quic]

Nadav, were you going to look at this? I'll come up with a fix otherwise...

[llvmbot]

Eli, I am starting to look at this bug. Thanks.

[efriedma-quic]

r144863.

[llvmbot]

This is not entirely fixed, here is another testcase, which also fails since r131183:
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
; ModuleID = 'temp.opt.bc'

define i32 @​main() {
BB0:
%r0 = alloca <4 x i32>, align 16
%r1 = getelementptr <4 x i32>* %r0, i32 0, i32 3
store i32 4, i32* %r1
%r2 = getelementptr <4 x i32>* %r0, i32 0, i32 2
store i32 3, i32* %r2
%r3 = getelementptr <4 x i32>* %r0, i32 0, i32 1
store i32 2, i32* %r3
%r4 = getelementptr inbounds <4 x i32>* %r0, i32 0, i32 0
store i32 1, i32* %r4
%r7 = load <4 x i32>* %r0, align 1
store i32 8, i32* %r1
store i32 7, i32* %r2
store i32 6, i32* %r3
store i32 5, i32* %r4
%r8 = load <4 x i32>* %r0, align 1
%r9 = extractelement <4 x i32> %r7, i32 2
%r10 = icmp eq i32 %r9, 3
br i1 %r10, label %BB4, label %BB1

BB4: ; preds = %BB0
%r11 = extractelement <4 x i32> %r8, i32 2
%r12 = icmp eq i32 %r11, 7
br i1 %r12, label %BB6, label %BB1

BB6: ; preds = %BB4
%r13 = extractelement <4 x i32> %r7, i32 3
%r14 = icmp eq i32 %r13, 4
br i1 %r14, label %BB8, label %BB1

BB8: ; preds = %BB6
br label %BB1

BB1: ; preds = %BB8, %BB6, %BB4, %BB0
%r17 = phi i32 [ 1, %BB0 ], [ 2, %BB4 ], [ 3, %BB6 ], [ 0, %BB8 ]
ret i32 %r17
}

Compile using:
llvm-as -o temp.bc bug.ll && llc -march=x86-64 -o temp.s temp.bc && gcc temp.s

This should exit with exit code 0, but it exits with code 3.

It looks like this load:
%r7 = load <4 x i32>* %r0, align 1
gets moved pasts the stores which alias it.

[efriedma-quic]

r147283.