[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