<div dir="ltr"><div><div>Currently opt simplifies<br><br>define float @test() {<br>  %Y = fptrunc double 1.0E+300 to float      ; yields undefined<br>  ret float %Y<br>}<br><br></div>to<br><br>define float @test() #0 {<br>  ret float 0x7FF0000000000000<br>}<br><div><br>This is the result I would expect based on the IEEE754 specification, but the documentation <a href="http://llvm.org/docs/LangRef.html#fptrunc-to-instruction" target="_blank">http://llvm.org/docs/LangRef.html#fptrunc-to-instruction</a> states that I should have expected an undef result.<br><br>I found these threads in the mailing list that look relevant:<br> - <a href="http://lists.llvm.org/pipermail/llvm-dev/2008-April/013560.html" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2008-April/013560.html</a><br> - <a href="http://lists.llvm.org/pipermail/llvm-dev/2013-March/060511.html" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2013-March/060511.html</a><br><br>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.<br></div><div>Where can I look up for further information?<br></div><div><br></div><div>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.<br><br></div>Is the documentation misleading or is this a missed optimization?<br><br></div><div>Andrea<br><br></div>PS: Apologies if you get this e-mail twice<br></div>