andrew.w.kaylor accepted this revision. andrew.w.kaylor added a comment. Thanks. I understand your direction for denormal handling now, and I'm OK with this patch apart from the remaining references to subnormal that Sanjay mentioned.
In D69598#1739723 <https://reviews.llvm.org/D69598#1739723>, @arsenm wrote: > I do think the floating point environment bits should be a considered a > property of the calling convention, with attributes that override them. A > function which calls a function with a different mode would be responsible > for switching the mode before the call. This would require people actually > caring about getting this right to really implement Do you mean the compiler should insert code to restore the FP environment on function transitions? Or do you mean that the function itself (i.e. the user's code) is responsible for switching the mode? I have some reservations about this, but I think the C standard specification for FENV_ACCESS is clear that the it is the programmer's responsibility to manage the floating point environment correctly. Yes, that's a sure recipe for broken code, but that's what it says. Obviously LLVM IR is not bound by the C standard and we could take a different approach, but I have concerns about the performance implications because in general the compiler won't know when the environment needs to be restored so it would have to take a conservative approach. I've been meaning to write some documentation on the expected behavior at function boundaries of the FP environment. Perhaps we can continue this discussion there. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69598/new/ https://reviews.llvm.org/D69598 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
