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

[Kevin P. Neal via cfe-dev]

I'm working with Andrew on D43515 right now, and some of these unanswered
questions are directly relevant to that patch. So....

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?

In D43515 the issue of what to do with STRICT_FP_TO_UINT is still unsolved.

>    that set (those bits in) the FP status register -- but the latter is
>    probably automatically done as long as those latter instructions are
>    described as having unmodeled side effects. Note that this will in
>    effect again create a dependency chain across all FP instructions, so
>    that B) should be implicitly covered as well here.
>    Did I miss anything here? I'm assuming that the behavior on FP
>    instructions on Intel (and other architectures) will be roughly
>    similar, given that this behavior is mostly defined by the IEEE
>    standard.
>    Now the question in my mind is, how this this all map onto the
>    experimental constrained intrinsics? They do have "rounding mode" and
>    "exception behavior" metadata, but I don't really see how that maps
>    onto the behavior of instructions as described above. Also, right now
>    the back-end doesn't even *get* at that data in the first place, since
>    it is just thown away when lowering the intrinsics to STRICT_... nodes.
>    In fact, I'm also not sure how the front-end is even supposed to be
>    *setting* those metadata flags -- is the compiler supposed to track
>    calls to fesetround and the like, and thereby determine which rounding
>    and exception modes apply to any given block of code? In fact, was the
>    original intention even that the back-end actually implements different
>    behavior based on this level of detail, or was the back-end supposed to
>    support only two modes, the default behavior of today and a fully
>    strict implementation always satisfying all three of A), B), and C)
>    above?
>    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? 

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?

-- 
Kevin P. Neal                                http://www.pobox.com/~kpn/

                    "A pig's gotta fly." - Crimson Pig