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

Zixuan Wu via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 25 18:23:30 PST 2019


wuzish added a comment.

In D55506#1408913 <https://reviews.llvm.org/D55506#1408913>, @kpn wrote:

> In D55506#1408435 <https://reviews.llvm.org/D55506#1408435>, @wuzish wrote:
>
> > I think we can have a flag to indicate rounding mode for float operator such as FADD instead of STRICT_FADD, because STRICT_FADD does have side effect(chain), but some target (eg. RISCV) has static rounding mode encoded in the instruction which does not side effect. Then we can optimize specific STRICT_FADD node which ignoring exception into normal FADD with corresponding static round mode.
>
>
> WRT the chain: "That's not a bug, that's a feature!"
>
> The chain prevents reordering of floating point instructions by the SelectionDAG. That makes it required.
>
> Some System/Z floating point instructions can take an optional per-instruction rounding mode encoded in the instruction. This does not eliminate the need for strict ordering of floating point operations.


Yes, the chain prevents redordering of floating point instructions by SelectionDAG. But it's fine to reorder instructions with static rounding mode(and ignore exception) and no need for chain. Because they do not have side effect, it means the result of such instructions only depend on input (eg, float add including source operands and mode encoding), does not depend on outside state variable that is current rounding mode. It also means the result is unchanged no matter how many times happens so long as the input is same.


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

https://reviews.llvm.org/D55506





More information about the llvm-commits mailing list