instcombine + dagcombine miscompilation

[asl]

Bugzilla Link	1014
Resolution	FIXED
Resolved on	Nov 07, 2018 00:17
Version	trunk
OS	All
Attachments	Test source

Extended Description

Consider the attached .ll file.

It will ask a number as input. Input "32".
Correct answer is "41". It can be obtained via cbackend. Both llc and lli
generate code, which produces "186".

[asl]

assigned to @lattner

[asl]

This is definitely bug in InstCombine.

opt -instcombine produces bad output

[llvmbot]

Hmm, no cast instructions.

What does instcombine produce? Can you attach it please?

Reid.

[asl]

Before:

    %ovm = and int %tmp1, 32                ; <int> [#uses=1]
    %ov3 = add int %ovm, 145                ; <int> [#uses=2]
    %ov110 = xor int %ov3, 153
    %hvar174 = add int %ov110, 1

After:

    %ovm = and int %tmp1, 32                ; <int> [#uses=1]
    %ov1102 = or int %ovm, 153              ; <int> [#uses=1]
    %hvar174 = add int %ov1102, 1           ; <int> [#uses=1]

[lattner]

Fixed. Testcase here: InstCombine/2006-11-27-XorBug.ll Patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061127/040292.html

-Chris

[asl]

Attached testcase is still broken.

[asl]

In fact, I haven't found any output difference before and after patch.

[lattner]

I get:
$ llvm-as < t.ll | opt -instcombine | llvm-dis
...
int %main() {
entry:
%v0 = alloca int, align 4 ; <int*> [#uses=2]
%tmp = call int (sbyte*, ...)* %scanf( sbyte* getelementptr ([3 x sbyte]* %str, int 0, uint 0), int* %v0
) ; [#uses=0]
%tmp1 = load int* %v0 ; [#uses=1]
%ovm = and int %tmp1, 32 ; [#uses=1]
%hvar1742 = or int %ovm, 9 ; [#uses=1]
%tmp3 = call int (sbyte*, ...)* %printf( sbyte* getelementptr ([4 x sbyte]* %str, int 0, uint 0), int %
hvar1742 ) ; [#uses=0]
br label %return

return: ; preds = %entry
ret int 0
}
..

You don't get this?

[lattner]

This same bug also exists in the dag combiner. Fixed like this:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061127/040294.html

-Chris