Currently opt simplifies
define float @test() {
%Y = fptrunc double 1.0E+300 to float ; yields undefined
ret float %Y
}
to
define float @test() #0 {
ret float 0x7FF0000000000000
}
This is the result I would expect based on the IEEE754 specification, but
the documentation http://llvm.org/docs/LangRef.html#fptrunc-to-instruction
states that I should have expected an undef result.
I found these threads in the mailing list that look relevant:
- http://lists.llvm.org/pipermail/llvm-dev/2008-April/013560.html
- http://lists.llvm.org/pipermail/llvm-dev/2013-March/060511.html
I was unable to find any answers to the latter and in the first one the
mismatch between the LLVM `fptrunc` definition and IEEE behaviour is
pointed out, but not actually discussed.
Where can I look up for further information?
I tried to go through some of the code (specifically, I found the constant
folding code this in APFloat.cpp:1972), but I was unable to find any way in
which it could generate an undef value.
Is the documentation misleading or is this a missed optimization?
Andrea
PS: Apologies if you get this e-mail twice
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160126/496a6cdd/attachment.html>