Open Kojoley opened 4 years ago
Before posting the bug report I have checked langref if IR float is IEEE-754, and it made me think that it is.
The binary format of half, float, double, and fp128 correspond to the IEEE-754-2008 specifications for binary16, binary32, binary64, and binary128 respectively.
That text looks familiar. :) https://reviews.llvm.org/rL328105
I need to review the earlier discussion, but IIRC, it wasn't enough that the format was as expected. We also had to be target-aware of how the operations are executed/approximated.
Before posting the bug report I have checked langref if IR float is IEEE-754, and it made me think that it is.
The binary format of half, float, double, and fp128 correspond to the IEEE-754-2008 specifications for binary16, binary32, binary64, and binary128 respectively.
I'm not sure if the addition of 'fneg' to the IR changed things, but bypassing a this kinds of transforms in IR was intentional because LLVM supports targets that are not IEEE754-compliant.
For reference: http://lists.llvm.org/pipermail/llvm-dev/2016-April/098098.html https://reviews.llvm.org/D19391
Extended Description
define float @foo(float %0) { %2 = fneg float %0 %3 = bitcast float %2 to i32 %4 = xor i32 %3, -2147483648 %5 = bitcast i32 %4 to float %6 = fneg float %5 %7 = bitcast float %6 to i32 %8 = xor i32 %7, -2147483648 %9 = bitcast i32 %8 to float ret float %9 }
Adding fast flag to fneg does not help.
https://godbolt.org/z/o9WQYp