> Conceptually the rounding mode is just a property. The call, in > effect, should demand a "normal" rounding mode and set the rounding > mode to unknown if I understand how this is supposed to work. If my > understanding is wrong, then maybe that's where we should start -- > with a good description of the problem ;-)
That's also what I what struggled with last time this was discussed. Normally, mode switching is used to switch to a requested mode for an insn or a call and potentially switch back afterwards. For those riscv intrinsics that specify a variable, non-default rounding mode we have two options: - Save and restore before and after each mode-changing intrinsic fegetround old_rounding fesetround new_rounding actual instruction fesetround old_rounding) - Have mode switching do it for us (lazily) to avoid most of the storing of the old rounding mode by storing an (e.g.) function-level rounding-mode backup value. The backup value is used to lazily restore the currently valid rounding mode. The problem with this now is that whenever fesetround gets called our backup is outdated. Therefore we need to update our backup after each function call (as fesetround can of course be present anywhere) and this is where most of the complications come from. So in that case the callee _does_ impact the caller via the backup clobbering. That was one of my complaints about the whole procedure last time. Besides, I didn't see the need for those intrinsics anyway and would much rather have explicit fesetround calls but well :) Having said that, it looks like Pan's patch just tries to move some of the dirty work from the backend to the mode-switching pass by making it easier to do something after a call. I believe I asked for that back in one of the reviews even? Regards Robin
