[llvm-dev] [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?

[Ulrich Weigand via llvm-dev]

"Kevin P. Neal" <kpn at neutralgood.org> wrote on 06.03.2018 15:01:46:
> On Fri, Feb 09, 2018 at 03:42:20PM +0100, Ulrich Weigand wrote:
> >    C) Floating-point exceptions
> >    If a mask bit in the floating-point status register is set, then all
FP
> >    instructions will *trap* whenever an IEEE exception condition is
> >    recognized. This means that we need to treat those instructions as
> >    having unmodelled side effects, so that they cannot be speculatively
> >    executed. Also, we cannot schedule FP instructions across
instructions
>
> Does this mean that the problems with the default expansion of
ISD::FP_TO_UINT
> would be solved by the backend knowing that it should model traps?

Not really.  The problem with the default FP_TO_UINT expansion is that it
implements FP_TO_UINT in terms of FE_TO_SINT, like so:

    x < INT_MAX+1 ? (signed) x : ((signed) (x - (INT_MAX+1)) + INT_MAX+1)

This is impemented via a "select", so that both paths are computed in
parallel.  If x is too large for the signed range (but within the unsigned
range), the (signed) x conversion will raise an FP_INEXACT exception, which
is not supposed to happen here.

I think this simplest way to fix this for the STRICT_ case is to use an
explicit "if" (two basic blocks and a phi node) instead of the "select",
using STRICT_FP_TO_SINT to implement the signed conversion.

The existing (or to be implemented) constraints on the strict nodes should
prevent instruction selection from converting the if back to a select.

> >    Looking again at a possible implementation in the back-end, I'm now
> >    wondering if it wouldn't after all be better to just treat the
STRICT_
> >    opcodes like all other DAG nodes. That is, have them be associated
with
> >    an action (Legal, Expand, or Custom); set the default action to
Expand,
> >    with a default expander that just replaces them by the "normal" FP
> >    nodes; and allow a back-end to set the action to Legal and/or Custom
> >    and then just handle them in the back-end as it sees fit. This might
> >    indeed require multiple patterns to match them, but it should be
> >    possible to generate those via multiclass instantiations so it might
> >    not be all that big a deal. The benefit would be that it allows the
> >    back-end the greatest freedom how to handle things (e.g.
interactions
> >    with target-specific control registers).
>
> Was there a consensus on what to do here?

I don't think we have a consensus yet.

> Are we exposing the strict SDAG nodes to the backend or not? Obviously
> if we are this isn't going to take a while to implement, but it would
> still be useful to know when coding the layers above the backend.
>
> If we're not exposing the strict nodes to the backend, would using the
> chain on expansions like ISD::FP_TO_UINT solve speculative execution
issues?

Well, any specific node like FP_TO_UINT either has a chain or it doesn't
have a chain.  So adding a chain to FP_TO_UINT would require us to add
it unconditionally, even if we didn't start out with strict nodes.

But that would impose scheduling constraints even on the non-strict case,
which I gather we don't really want to see.

So it appears to me that if we need a chain (or control register
dependencies etc.), it would be easier on the back-end anyway to
have a different ISD node, in which case it just might be the easiest
to pass the STRICT_ nodes through to the back-end if it wants ...

I'll try and go ahead with the SystemZ back-end to see how complicated
it would actually be to add those nodes, so that we can make an
informed decision.

Bye,
Ulrich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180306/e3cdf5e8/attachment-0001.html>