andrew.w.kaylor added a comment. In D62731#1782912 <https://reviews.llvm.org/D62731#1782912>, @rjmccall wrote:
> Hmm. The target-specific intrinsics thing does concern me, since I assume > many targets have a bunch of vector intrinsics that may be sensitive to > rounding. Do we have an idea of how we'd fix that? If it's a short-term > incorrectness that we have a plan to fix, I don't mind the risk, but if we > don't know how we'd even start to address it... I see two potential problem cases with the target-specific intrinsics: 1. Some optimization pass recognizes the intrinisic and uses its semantics to perform some optimization such as constant folding 2. Some optimization performs code motion that moves the intrinsic (or, in the backend, the instruction it represents) across an operation that changes the rounding mode I don't know if there are any instances of the first case in the public repository. Downstream users could be doing it. Those will need special handling if they exist (checking for the the strictfp attribute). The second case should be handled in IR by fesetround() or other such intrinsics being marked as having side effects. It's possible that there are target-specific intrinsics to change the rounding mode that aren't marked as having side effects, but if so that's simply a bug. The other part of this is that the intrinsic might be lowered to MC and the MC instructions in a way that neglects rounding mode. Many targets have instructions with forms that take an explicit rounding mode argument and the backends may be using that with the default rounding mode. I am not aware of any such case, but it's definitely possible. Finally, our design for handling strict fp mode in the backends is that rounding mode control will be handled by explicitly modeling the dependency between the relevant control registers and instructions that implicitly use the rounding mode controled by those registers. X86 only recently started doing this. There may be other backends that have not implemented it. Some may never do so. I don't have a strong preference about what to do with the warning. I have a slight preference for replacing the existing warning with a more specific warning saying that floating math support is a work in progress. Eventually we need a way for backends to indicate that they believe their support is complete. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62731/new/ https://reviews.llvm.org/D62731 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
