miscompilation due to gcc inliner?

[regehr]

Bugzilla Link	2999
Resolution	FIXED
Resolved on	Jan 18, 2009 20:52
Version	unspecified
OS	Linux
Depends On	llvm/llvm-bugzilla-archive#3232
Attachments	failure-inducing input
CC	@asl,@isanbard

Extended Description

This testcase, unfortunately, is kind of ugly and scary. It appears to be miscompiled by LLVM r58541 on Ubuntu Hardy on x86. This is a regression since 2.3.

regehr@john-home:/volatile/tmp55$ llvm-gcc -O0 small.c -o small
regehr@john-home:/volatile/tmp55$ ./small
0
regehr@john-home:/volatile/tmp55$ llvm-gcc -O1 small.c -o small
regehr@john-home:/volatile/tmp55$ ./small
1

[isanbard]

When inlining the @​rshift_u_s function, it elides some important instructions:

...
%14 = tail call fastcc i32 @​rshift_u_s(i32 %13, i32 %7) nounwind
...

define internal fastcc i32 @​rshift_u_s(i32 %left, i32 %right) nounwind readnone {
entry:
%0 = icmp slt i32 %right, 0
%1 = icmp ugt i32 %right, 31
%or.cond = or i1 %0, %1
%2 = select i1 %or.cond, i32 0, i32 %right
%left. = lshr i32 %left, %2
ret i32 %left.
}

Becomes:

    %16 = icmp ugt i32 %7, 31
    %17 = select i1 %16, i32 0, i32 %7
    %.. = lshr i32 %., %17

which is wrong.

[isanbard]

This appears to be happening due to the llvm-gcc inliner, not the llvm inliner.

[regehr]

Reconfirmed on 12/8/08.

[llvmbot]

This doesn't seem to having anything to do with the inliner.
As far as I can see it is a codegen bug occurring when the
frame pointer is not eliminated. With the attached bytecode:

$ llc x.bc -f
$ gcc -o x x.s && ./x
0
$ llc x.bc -f -disable-fp-elim
$ gcc -o x x.s && ./x
1

[llvmbot]

testcase.ll
Testcase showing codegen problem.

[llvmbot]

PS: About this comment

When inlining the @​rshift_u_s function, it elides some important instructions:
...
which is wrong.

The transform seems correct to me. The point is that the
first comparison in
%0 = icmp slt i32 %right, 0
%1 = icmp ugt i32 %right, 31
%or.cond = or i1 %0, %1
is redundant, because if %right is less than zero,
considered as a signed quantity, then it is bigger
than some huge number like 2^31 when considered as
an unsigned quantity, in particular bigger than 31.
Thus if %0 is true then %1 is true. So only the
second test matters.

[lattner]

This appears to work on mainline.

[lattner]

mentioned in issue llvm/llvm-bugzilla-archive#3232