[llvm-dev] The semantics of the fptrunc instruction with an example of incorrect optimisation

[Dan Liew via llvm-dev]

Hi,

>
> This sounds like https://llvm.org/bugs/show_bug.cgi?id=8100 : complete
> support for FP rounding and exceptions (via `#pragma STDC FENV_ACCESS
> ON', which you need for fesetround to be "meaningful") isn't
> implemented yet (and is probably a huge task, as you explain).
>

Thanks. I wasn't aware of ``STDC FENV_ACCESS``.

Supporting something like this no doubt is difficult. One way I could
imagine supporting rounding in a more general way would be to have all
floating point operations at the IR level take a rounding mode operand
(would let you do correctly rounded constant folding in all cases).
When doing codegen for something like x86 the most simplistic thing
you could do is reset the rounding mode for every floating point
operation but I could imagine handling this more efficiently by
computing call-free (functions known not to modify the rounding mode
could be ignored) single-entry-single-exit regions where the rounding
mode does not change and omitting rounding mode reset instructions
there. I'm not really sure if this is a good idea, if there aren't any
real world targets that make the rounding mode part of instruction
op-codes then it feels like this would be forcing a virtual machine
model in LLVM IR that although useful for static analysis poorly
reflects what real machines do.

 However some low hanging fruit that could be addressed pretty quickly
would be to give better semantics to ``fptrunc`` based on how it is
codegened by targets currently. For x86 it seems to mean convert a
floating point number to a lower precision type using the current
rounding mode of the floating point environment. I don't really know
what the other targets do though so someone who has a broader overview
than me needs to rewrite the semantics.

Thanks,
Dan.