llvm dev - Mar 2017 - Is it a valid fp transformation?

This C program produces different results with -O0 and -O3 optimization levels.

#include <stdio.h>
float test(unsigned int arg) {
    return (float)((int)(arg * 58)) + 1;
}
int main() {
    printf("%d\n", (int)test((unsigned int)-831710640));
}

O0 result is -994576896
O3 result is -994576832

It happens because LLVM (specifically instcombine) does the following
transformation:
(float)x + 1.0 => (float)(x + 1)

For some values the expression before and after yield different results:
                  x = -994576864
         (float)x = -994576896.000000
(float)x + 1.0 = -994576896.000000
(float)(x + 1) = -994576832.000000

I’m curious if this is a correct transformation and why.

Artur

Looks broken to me; I don't think there's UB in the original program.

The fold in visitFAdd() should check if the sitofp is guaranteed to produce
an exact result? Ie, if the int value input to the sitofp could possibly be
different when converted back using fptosi, then the transform does not
work.

define float @test(i32 %x) {
  %mul = mul i32 %x, 58
  %conv = sitofp i32 %mul to float
  %add = fadd float %conv, 1.0
  ret float %add
}


On Mon, Mar 20, 2017 at 4:25 AM, Artur Pilipenko <apilipenko at azul.com>
wrote:
> This C program produces different results with -O0 and -O3 optimization
> levels.
>
> #include <stdio.h>
> float test(unsigned int arg) {
>     return (float)((int)(arg * 58)) + 1;
> }
> int main() {
>     printf("%d\n", (int)test((unsigned int)-831710640));
> }
>
> O0 result is -994576896
> O3 result is -994576832
>
> It happens because LLVM (specifically instcombine) does the following
> transformation:
> (float)x + 1.0 => (float)(x + 1)
>
> For some values the expression before and after yield different results:
>                   x = -994576864
>          (float)x = -994576896.000000
> (float)x + 1.0 = -994576896.000000
> (float)(x + 1) = -994576832.000000
>
> I’m curious if this is a correct transformation and why.
>
> Artur
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170320/32b4e3ed/attachment.html>

I agree. There’s implementation-defined behavior on the conversion of (arg*58)
to int, but that shouldn’t be at issue here. The transform of (float)x + 1 =>
(float)(x + 1) is bogus.
> On Mar 20, 2017, at 10:41 AM, Sanjay Patel via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Looks broken to me; I don't think there's UB in the original
program.
> 
> The fold in visitFAdd() should check if the sitofp is guaranteed to produce
an exact result? Ie, if the int value input to the sitofp could possibly be
different when converted back using fptosi, then the transform does not work.
> 
> define float @test(i32 %x) {
>   %mul = mul i32 %x, 58
>   %conv = sitofp i32 %mul to float
>   %add = fadd float %conv, 1.0
>   ret float %add
> }
> 
> 
> On Mon, Mar 20, 2017 at 4:25 AM, Artur Pilipenko <apilipenko at azul.com
<mailto:apilipenko at azul.com>> wrote:
> This C program produces different results with -O0 and -O3 optimization
levels.
> 
> #include <stdio.h>
> float test(unsigned int arg) {
>     return (float)((int)(arg * 58)) + 1;
> }
> int main() {
>     printf("%d\n", (int)test((unsigned int)-831710640));
> }
> 
> O0 result is -994576896
> O3 result is -994576832
> 
> It happens because LLVM (specifically instcombine) does the following
transformation:
> (float)x + 1.0 => (float)(x + 1)
> 
> For some values the expression before and after yield different results:
>                   x = -994576864
>          (float)x = -994576896.000000
> (float)x + 1.0 = -994576896.000000
> (float)(x + 1) = -994576832.000000
> 
> I’m curious if this is a correct transformation and why.
> 
> Artur
> 
> 
> _______________________________________________
> 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/20170320/75914f8b/attachment.html>