search for: strict_

...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...

Ulrich Weigand/Germany/IBM wrote on 06.03.2018 16:07:34: > 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. I've now implemented the above to handle all the currently supported S...

...g 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 orig...

I think we're going to need to create a new mechanism to communicate strict FP modes to the backend. I think we need to avoid doing anything that will require re-inventing or duplicating all of the pattern matching that goes on in instruction selection (which is the reason we're currently dropping that information). I'm out of my depth on this transition, but I think maybe we could

Andrew Kaylor wrote: >In general, the current "strict FP" handling stops at instruction >selection. At the MachineIR level we don't currently have a mechanism >to prevent inappropriate optimizations based on floating point >constraints, or indeed to convey such constraints to the backend. >Implicit register use modeling may provide some restriction on some