Hi Pan, thanks for your patience and your work. Apart from my general doubt whether mode-changing intrinsics are a good idea, I don't have other remarks that need fixing. What I mentioned before:
- Handling of asms wouldn't be a huge change. It can be done in a follow-up patch of course but should be done eventually. - The code is still rather difficult to follow because we diverge from the usual mode-switching semantics e.g. in that we emit insns in mode_needed as well as in mode_set. I would have preferred to stay close to the regular usage, document where and why we need to do something different and suggest future middle-end improvements to solve this more elegantly. - I hope non-local control flow like setjmp/longjmp, sibcall optimization and maybe others work fine. I didn't see a reason why not but I haven't checked very closely either. - We can probably get away with not annotating every call with an FRM clobber because there isn't any pass that would make use of that anyway? As to my general qualm, independent of this patch, quickly summarized again one last time (the problem was latent before this specific patch anyway): I would prefer not to have mode-changing intrinsics at all but have users call fesetround explicitly. That way the exact point where the rounding mode is changed would be obvious and not subject to optimization as well as caching/backing up. If at all necessary I would have preferred the LLVM way of backing up, setting new mode, performing the instruction and restoring directly after. If the initial intent of mode-changing intrinsics was to give users more control, I don't believe we achieve this by the "lazy" restore mechanism which is rather an obfuscation. Pardon my frankness but the whole mode-changing thing feels to me like just getting a feature out of the door to solve "something" /appease users than a well thought-out feature. It doesn't even seem clear if this optimization is worthwhile when changing the rounding mode is prohibitively slow anyway. That said, if the current status is what the majority of contributors can live with, I'm not going to stand in the way, but I'd ask Kito or somebody else to give the final OK. Regards Robin
