<html><body><p><tt><font size="2">"Kevin P. Neal" <kpn@neutralgood.org> wrote on 06.03.2018 15:01:46:<br>> On Fri, Feb 09, 2018 at 03:42:20PM +0100, Ulrich Weigand wrote:<br>> > C) Floating-point exceptions<br>> > If a mask bit in the floating-point status register is set, then all FP<br>> > instructions will *trap* whenever an IEEE exception condition is<br>> > recognized. This means that we need to treat those instructions as<br>> > having unmodelled side effects, so that they cannot be speculatively<br>> > executed. Also, we cannot schedule FP instructions across instructions<br>> <br>> Does this mean that the problems with the default expansion of ISD::FP_TO_UINT<br>> would be solved by the backend knowing that it should model traps?<br></font></tt><br><tt><font size="2">Not really. The problem with the default FP_TO_UINT expansion is that it</font></tt><br><tt><font size="2">implements FP_TO_UINT in terms of FE_TO_SINT, like so:</font></tt><br><br><tt><font size="2"> x < INT_MAX+1 ? (signed) x : ((signed) (x - (INT_MAX+1)) + INT_MAX+1)</font></tt><br><br><tt><font size="2">This is impemented via a "select", so that both paths are computed in</font></tt><br><tt><font size="2">parallel. If x is too large for the signed range (but within the unsigned</font></tt><br><tt><font size="2">range), the (signed) x conversion will raise an FP_INEXACT exception, which</font></tt><br><tt><font size="2">is not supposed to happen here.</font></tt><br><br><tt><font size="2">I think this simplest way to fix this for the STRICT_ case is to use an</font></tt><br><tt><font size="2">explicit "if" (two basic blocks and a phi node) instead of the "select",</font></tt><br><tt><font size="2">using STRICT_FP_TO_SINT to implement the signed conversion.</font></tt><br><br><tt><font size="2">The existing (or to be implemented) constraints on the strict nodes should</font></tt><br><tt><font size="2">prevent instruction selection from converting the if back to a select.</font></tt><br><tt><font size="2"><br>> > Looking again at a possible implementation in the back-end, I'm now<br>> > wondering if it wouldn't after all be better to just treat the STRICT_<br>> > opcodes like all other DAG nodes. That is, have them be associated with<br>> > an action (Legal, Expand, or Custom); set the default action to Expand,<br>> > with a default expander that just replaces them by the "normal" FP<br>> > nodes; and allow a back-end to set the action to Legal and/or Custom<br>> > and then just handle them in the back-end as it sees fit. This might<br>> > indeed require multiple patterns to match them, but it should be<br>> > possible to generate those via multiclass instantiations so it might<br>> > not be all that big a deal. The benefit would be that it allows the<br>> > back-end the greatest freedom how to handle things (e.g. interactions<br>> > with target-specific control registers).<br>> <br>> Was there a consensus on what to do here? <br></font></tt><br><tt><font size="2">I don't think we have a consensus yet.</font></tt><br><tt><font size="2"> <br>> Are we exposing the strict SDAG nodes to the backend or not? Obviously<br>> if we are this isn't going to take a while to implement, but it would<br>> still be useful to know when coding the layers above the backend.<br>> <br>> If we're not exposing the strict nodes to the backend, would using the<br>> chain on expansions like ISD::FP_TO_UINT solve speculative execution issues?<br></font></tt><br><tt><font size="2">Well, any specific node like FP_TO_UINT either has a chain or it doesn't</font></tt><br><tt><font size="2">have a chain. So adding a chain to FP_TO_UINT would require us to add</font></tt><br><tt><font size="2">it unconditionally, even if we didn't start out with strict nodes.</font></tt><br><br><tt><font size="2">But that would impose scheduling constraints even on the non-strict case,</font></tt><br><tt><font size="2">which I gather we don't really want to see.</font></tt><br><br><tt><font size="2">So it appears to me that if we need a chain (or control register</font></tt><br><tt><font size="2">dependencies etc.), it would be easier on the back-end anyway to</font></tt><br><tt><font size="2">have a different ISD node, in which case it just might be the easiest</font></tt><br><tt><font size="2">to pass the STRICT_ nodes through to the back-end if it wants ...</font></tt><br><br><tt><font size="2">I'll try and go ahead with the SystemZ back-end to see how complicated</font></tt><br><tt><font size="2">it would actually be to add those nodes, so that we can make an</font></tt><br><tt><font size="2">informed decision.</font></tt><br><br><tt><font size="2">Bye,</font></tt><br><tt><font size="2">Ulrich</font></tt><br><BR>
</body></html>