search for: strict_fp_to_uint

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

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