[PATCH] D66092: [CodeGen] Generate constrained fp intrinsics depending on FPOptions

andrew.w.kaylor added a comment. It took some digging, but I finally found the e-mail thread where we initially agreed that we can't mix constrained FP intrinsics and non-constrained FP operations within a function. Here it is: http://lists.llvm.org/pipermail/cfe-dev/2017-August/055325.html

[PATCH] D66092: [CodeGen] Generate constrained fp intrinsics depending on FPOptions

andrew.w.kaylor added a comment. In D66092#1632642 , @sepavloff wrote: > - What is the issue with moving `a = b/c`? If it moves ahead of `if` > statement it seems OK, because the rounding mode is the same in that point. > It cannot be moved inside the

[PATCH] D66092: [CodeGen] Generate constrained fp intrinsics depending on FPOptions

sepavloff added a comment. > The thing that makes the IR semantically incomplete is that there is nothing > there to prevent incorrect code motion of the non-constrained operations. > Consider this case: > > if (someCondition) { > #pragma clang fp rounding(downward) >

[PATCH] D66092: [CodeGen] Generate constrained fp intrinsics depending on FPOptions

andrew.w.kaylor added a comment. In D66092#1630997 , @sepavloff wrote: > Replacement of floating point operations with constrained intrinsics seems > more an optimization helper then a semantic requirement. IR where constrained > operations are mixed

[PATCH] D66092: [CodeGen] Generate constrained fp intrinsics depending on FPOptions

sepavloff added a comment. In D66092#1629460 , @andrew.w.kaylor wrote: > In D66092#1627339 , @sepavloff wrote: > > > In D66092#1625380 , @kpn wrote: > > > > > Also, if any

[PATCH] D66092: [CodeGen] Generate constrained fp intrinsics depending on FPOptions

andrew.w.kaylor added a comment. In D66092#1627339 , @sepavloff wrote: > In D66092#1625380 , @kpn wrote: > > > Also, if any constrained intrinsics are used in a function then the entire > > function needs to be

[PATCH] D66092: [CodeGen] Generate constrained fp intrinsics depending on FPOptions

sepavloff added a comment. In D66092#1625380 , @kpn wrote: > Does this work for anything that uses TreeTransform, like C++ templates? Added such tests. > Also, if any constrained intrinsics are used in a function then the entire > function needs to be

[PATCH] D66092: [CodeGen] Generate constrained fp intrinsics depending on FPOptions

sepavloff updated this revision to Diff 214857. sepavloff added a comment. Added tests for 'pragma clang fp' in template instantiations Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D66092/new/ https://reviews.llvm.org/D66092 Files:

[PATCH] D66092: [CodeGen] Generate constrained fp intrinsics depending on FPOptions

kpn added a comment. Does this work for anything that uses TreeTransform, like C++ templates? Also, if any constrained intrinsics are used in a function then the entire function needs to be constrained. Is this handled anywhere? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D66092: [CodeGen] Generate constrained fp intrinsics depending on FPOptions

sepavloff created this revision. sepavloff added reviewers: rjmccall, anemet, kpn, aaron.ballman, hfinkel. Herald added a project: clang. If the value of FPOption is modified, for example by using pragma 'clang fp', create calls to constrained fp intrinsics with metadata arguments corresponding