Open Quuxplusone opened 4 years ago
Bugzilla Link | PR44622 |
Status | NEW |
Importance | P normal |
Reported by | Nikita Kniazev (nok.raven@gmail.com) |
Reported on | 2020-01-22 07:29:59 -0800 |
Last modified on | 2020-03-31 06:34:10 -0700 |
Version | trunk |
Hardware | All All |
CC | htmldeveloper@gmail.com, kamleshbhalui@gmail.com, llvm-bugs@lists.llvm.org, llvm-dev@redking.me.uk, spatel+llvm@rotateright.com |
Fixed by commit(s) | |
Attachments | |
Blocks | |
Blocked by | |
See also | PR45306 |
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
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.
https://llvm.org/docs/LangRef.html#floating-point-types
(In reply to Nikita Kniazev from comment #2)
> 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.
>
> https://llvm.org/docs/LangRef.html#floating-point-types
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.