[PATCH] D55506: [RFC v2] Allow target to handle STRICT floating-point nodes

[Zixuan Wu via Phabricator via llvm-commits]

wuzish added a comment.

In D55506#1560499 <https://reviews.llvm.org/D55506#1560499>, @uweigand wrote:

> In D55506#1560331 <https://reviews.llvm.org/D55506#1560331>, @wuzish wrote:
>
> > I have another question about any_*.
> >
> > For example, I see you use any_fadd to match both fadd and strict_fadd. I guess ZSystem target is similar to POWER that there is no fp addition machine instruction with nearest rounding mode and no exception statically. 
> >  But the semantic of fadd node requires. So theoretically, fadd node should be mapped into 2 instructions for correct compiling. One sets rounding mode to nearest and clear exception handler bit(no exception happens), the other is float addition.
> >  Do we not handle fadd like above because there is no function error for such fine-grained instruction semantic mostly? And avoid performance penalty? @uweigand
>
>
> I believe you may be misunderstanding the semantics of the non-strict operations.  These do *not* instruct codegen to actively generate code to switch rounding modes and/or clear exception bits.  Rather, the use of a non-strict operation like fadd is an *assertion* that tells codegen that it may *assume* that the rounding mode is set to default, trapping exceptions are switched off, and exceptions flags are don't care (i.e. subsequent code will not check them).   If you ever use fadd in a context where this assumption is not true, the behaviour is undefined.  This means it is perfectly correct to implement fadd using the "normal" floating-point instruction.
>
> Note that similarly, if a strict operation with a given rounding mode flag is used, this likely does *not* instruct coegen to actively generate code to implement this particular rounding mode.  Rather, this is again simply an *assertion* that tells codegen that it may *assume* the current rounding mode is set to this specific value.  Again, this means that it is perfectly correct to implement such an operation using the "normal" floating-point instruction that will use the current rounding mode.


Thank you. I think I got what you said. Dynamic rounding mode can be applied to static rounding mode so long as the environment rounding mode is correct set by other user/system code before. So to avoid the UB, initial work of environment(clear exception and set rounding mode to nearest) can be done at the beginning of program, maybe in runtime library.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55506/new/

https://reviews.llvm.org/D55506