Try to clarify semantics of fptrunc

[Dan Gohman via llvm-commits]

Clarifying that 'fptrunc' is not necessarily a truncation is indeed an
improvement. It looks like WebAssembly CodeGen was previously nonconforming
to LLVM's rules in that detail, because it's following the IEEE 754
semantics.

Dan

On Fri, Aug 28, 2015 at 8:09 PM, Sean Silva <chisophugis at gmail.com> wrote:

> +destination type, ``ty2``, then the results are undefined. If the cast
> produces
> +an inexact result how rounding is performed (e.g. truncation, also known
> as
> +round to zero) is undefined.
>
> probably want a comma between `result` and `how`
>
> Other than that, this looks fine. I'd like a second opinion from Dan
> Gohman though since he has recently defined a target's floating point
> lowering.
>
> -- Sean Silva
>
> On Fri, Aug 28, 2015 at 11:51 AM, Dan Liew <dan at su-root.co.uk> wrote:
>
>> Hi,
>>
>> This patch follows on from an e-mail I sent to llvm-dev a while ago [1].
>>
>> The issue I see is that the documented semantics of ``fptrunc`` are
>> misleading
>>
>> * ``the value cannot fit within the destination type`` is ambiguous.
>>   It could mean overflow or an inexact result that requires rounding or
>>   it could mean both.
>>
>> * Using "truncation" in the semantics is very misleading given that it
>>   doesn't necessarily truncate (i.e. round to zero). For example on
>>   x86_64 with SSE2 this is currently mapped to cvtsd2ss instruction
>>   who's rounding behaviour is dependent on the MXCSR register which
>>   is usually set to round to nearest even by default.
>>
>> This patch tries to address this.
>>
>>
>> [1] http://lists.llvm.org/pipermail/llvm-dev/2015-August/089504.html
>>
>> Thanks,
>> Dan
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150902/06298272/attachment.html>