<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 2, 2015 at 11:21 PM, Dan Liew <span dir="ltr"><<a href="mailto:dan@su-root.co.uk" target="_blank">dan@su-root.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 2 September 2015 at 15:11, Dan Gohman <<a href="mailto:sunfish@mozilla.com" target="_blank">sunfish@mozilla.com</a>> wrote:<br>
> Clarifying that 'fptrunc' is not necessarily a truncation is indeed an<br>
> improvement. It looks like WebAssembly CodeGen was previously nonconforming<br>
> to LLVM's rules in that detail, because it's following the IEEE 754<br>
> semantics.<br>
<br>
</span>This change makes it explicit that the rounding mode is not defined so<br>
I don't understand what you mean by the WebAssembly CodeGen being non<br>
conforming. The rounding mode can be anything, including any one of<br>
the five IEEE754 rounding modes.<br></blockquote><br></div><div class="gmail_quote">LLVM's LangRef previously said that fptrunc always truncates. It doesn't, on many common platforms, including WebAssembly. Your patch fixes that problem.<br></div><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Although this is an improvement I think it would be better if fptrunc<br>
actually took an operand that specified the rounding mode. It would<br>
make static analysis easier, constant folding more correct and could<br>
be used by backends that support different rounding modes. This change<br>
would have a lot of impact though so I opted for the simpler change of<br>
just making the poorly defined behaviour of ``fptrunc`` more explicit.<br></blockquote><div><br></div><div>I agree that such a change would have far broader implications. I'd expect a change like this to be designed at the C/C++ language level first.<br><br></div><div>Dan<br><br></div></div></div></div>