[llvm-dev] Code which should exit 1 is exiting 0
Pete Cooper via llvm-dev
llvm-dev at lists.llvm.org
Wed May 4 22:37:35 PDT 2016
I was curious about this for integers. Looks like we have at least one bug which is of a similar vein. Comment out the branch here and the test will pass on x86, otherwise it fails.
Note, command line I used was: llc int.ll -o int.s --filetype=asm && clang++ int.s -o main && ./main; echo $?
@g = constant i8 255
define i32 @main() {
%ptr = bitcast i8* @g to i7*
%v7 = load i7, i7* %ptr
; br label %cmp
; cmp:
%add7 = add i7 %v7, 1
%icmp = icmp eq i7 %add7, 0
br i1 %icmp, label %eq, label %ne
eq:
ret i32 0
ne:
ret i32 1
}
Pete
> On May 4, 2016, at 6:04 PM, via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> DAG legalization still runs with -O0.
>
> —escha
>
>> On May 4, 2016, at 6:00 PM, Carlos Liam <carlos at aarzee.me <mailto:carlos at aarzee.me>> wrote:
>>
>> Shouldn't that not happen when I run with -O0?
>>
>> - CL
>>
>>> On May 4, 2016, at 8:56 PM, escha at apple.com <mailto:escha at apple.com> wrote:
>>>
>>> I checked the debug log: this is what’s happening.
>>>
>>> 1. Because f16 isn’t legal, SINT_TO_FP and FP_TO_SINT get promoted to f32.
>>> 2. f32 has 24 mantissa bits, which is enough to losslessly represent i16s. So the conversion gets eliminated in FoldIntToFPToInt.
>>>
>>> Part 1) here looks fairly suspicious.
>>>
>>> —escha
>>>
>>>> On May 4, 2016, at 5:41 PM, John Criswell via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>>>
>>>> On 5/4/16 8:25 PM, Carlos Liam via llvm-dev wrote:
>>>>> I have IR at https://ghostbin.com/paste/daxv5 <https://ghostbin.com/paste/daxv5> which is meant to exit 1, but it is always exiting 0.
>>>>>
>>>>
>>>> 1) It would help if you pasted the relevant code into your message. Paranoid people like me don't following links in emails.
>>>>
>>>> 2) Have you ensured that your program doesn't exercise undefined behavior? If your program has a signed overflow, an out-of-bounds error, or some other undefined behavior, the compiler may optimize it in surprising and unexpected way.
>>>>
>>>> Regards,
>>>>
>>>> John Criswell
>>>>
>>>>> I'm using it as a template for checking if two functions @test1 and @test2 are equivalent by checking against the exhaustive possible i16 values. For this particular example it should be enough to know that for certain i16, @test1 and @test2 are *not* equal. When an inequality is found, the program should exit 1. However, it seems like it's always exiting 0. Is there something I'm doing wrong?
>>>>>
>>>>> - CL
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>>>
>>>>
>>>> --
>>>> John Criswell
>>>> Assistant Professor
>>>> Department of Computer Science, University of Rochester
>>>> http://www.cs.rochester.edu/u/criswell <http://www.cs.rochester.edu/u/criswell>_______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160504/6adb969f/attachment.html>
More information about the llvm-dev
mailing list