Code which should exit 1 is exiting 0

Project Infrastructure LLVM Dev List Archives
1

I have IR at https://ghostbin.com/paste/daxv5 which is meant to exit 1, but it is always exiting 0.

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
2

How are you compiling it? For which target?

—escha

3

I’m using lli, on x86-64.

  • CL
4
  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
5

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

6

DAG legalization still runs with -O0.

—escha

7

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

8

I filed a shorter version of the i7 example here:
https://llvm.org/bugs/show_bug.cgi?id=27825