[llvm-bugs] [Bug 49092] New: [Pwr8] legalization of bitcast between i16 to half

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=49092

            Bug ID: 49092
           Summary: [Pwr8] legalization of bitcast between i16 to half
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: PowerPC
          Assignee: unassignedbugs at nondot.org
          Reporter: v.churavy at gmail.com
                CC: llvm-bugs at lists.llvm.org, nemanja.i.ibm at gmail.com

```
define half @convert(i16 %in) {
  %f = bitcast i16 %in to half
  ret half %f
}
```

llc -mcpu=pwr8 

```
        clrldi  3, 3, 32
        bl __gnu_h2f_ieee
```

as far as I can tell this clears the upper 32 bits of `r3` and not the upper 48
bits.
`__gnu_h2f_ieee` expects a call with i16 and having non-zero higher bits can
trip up some implementations. Seen in the wild as
https://github.com/JuliaLang/julia/issues/39330 with

https://gist.github.com/vchuravy/7f7f21dadc93fb4f0aea3b5f236e360c as a
reproducer:

```
[vchuravy at service0001 jl-pwr8]$ gcc  -O2 -g2 -mcpu=power8 -c -fpic half.c       
[vchuravy at service0001 jl-pwr8]$ gcc -shared -o libhalf.so half.o                
[vchuravy at service0001 jl-pwr8]$ ../toolchain/tools/clang -mcpu=pwr8 main.ll
-L`pwd` -Wl,-rpath=`pwd` -lhalf
[vchuravy at service0001 jl-pwr8]$ ./a.out; echo $?                                
0
```

The expected answer for this reproducer is `1`. 

Looking at that reproducer with GDB and I got the following result:

Run till exit from #0  __gnu_h2f_ieee (param=31744) at
/nobackup/users/vchuravy/dev/julia/src/intrinsics.cpp:1488
0x00000000100008f0 in julia_g_219 ()
Value returned is $1 = -inf
Run till exit from #0  __gnu_h2f_ieee (param=31744) at
/nobackup/users/vchuravy/dev/julia/src/intrinsics.cpp:1488
0x0000000010000944 in julia_g_219 ()
Value returned is $5 = inf

GDB thinks we are calling it with the same `param`, but we are passing the
argument in r3, which on the call that yields the wrong result is:
r3             0xffff7c00 4294933504

and on a call where it is the right result:
r3             0x7c00 31744

so the caller didn't clear the upper bits.
Indeed just before the call we do:

   0x00000000100008e4 <+228>: mr      r4,r3
   0x00000000100008e8 <+232>: clrldi  r3,r4,32
=> 0x00000000100008ec <+236>: bl      0x100005e0
<00000017.plt_call.__gnu_h2f_ieee>

Now a different question could be: Why are there spurious bit where there
should be none.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210208/4461d6b6/attachment.html>