Try to clarify semantics of fptrunc

[Jonathan Roelofs via llvm-commits]

On 9/3/15 2:30 PM, JF Bastien via llvm-commits wrote:
> On Thu, Sep 3, 2015 at 11:26 AM, Dan Liew <dan at su-root.co.uk> wrote:
>>> How would that work for C/C++? I may be lacking creativity, but I
>>> think clang would need to generate a built-in "rounding mode"
>>> thread-local value,
>>
>> I was under the impression that the rounding mode was already part of
>> thread local storage (at least for C11) which is retrievable with
>> fegetround() and modified using fesetround().
>> Although C's definition of rounding modes is poor (e.g. doesn't define
>> how ties are handled when doing rounding to nearest AFAIK) and doesn't
>> include all of IEEE 754's rounding modes.
>
> Yes it's thread local in the language, but the storage is an
> implementation detail which LLVM currently doesn't model (it's in the
> current CPU state). Modeling it gives LLVM more information... and
> bloats the IR. Also, "pure" and "no read" functions that do strict FP
> aren't pure anymore!

Seems to my untrained ear that the lack of purity is a shortcoming of 
each particular arch+backend then. One could imagine an implementation 
that preserves some sense of "purity" via saving & restoring these 
states at appropriate places as needed.


Jon

>
> In a way it would need to be modeled as flags are, which is to say
> individually by each backend, with some magical "i1" that they have to
> disambiguate.
>

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded