search for: thown

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

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

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

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