mibintc added a comment.
In D62731#1620174 <https://reviews.llvm.org/D62731#1620174>, @andrew.w.kaylor wrote: > I'm not entirely caught up on this review. I've only read the most recent > comments, but I think I've got enough context to comment on the metadata > arguments. > > Based only on the fp-model command line options, the front end should only > ever use "round.dynamic" (for strict mode) or "round.tonearest" (where full > fenv access isn't permitted but we want to enable strict In D62731#1620174 <https://reviews.llvm.org/D62731#1620174>, @andrew.w.kaylor wrote: > I'm not entirely caught up on this review. I've only read the most recent > comments, but I think I've got enough context to comment on the metadata > arguments. > > Based only on the fp-model command line options, the front end should only > ever use "round.dynamic" (for strict mode) or "round.tonearest" (where full > fenv access isn't permitted but we want to enable strict exception > semantics). There are some pragmas, which I believe are in some draft of a > standards document but not yet approved, which can declare any of the other > rounding modes, but I don't know that we have plans to implement those yet. > I'm also hoping that at some point we'll have a pass that finds calls to > fesetround() and changes the metadata argument when it can prove what the > rounding mode will be. > > For the fp exception argument, the only values that can be implied by the > -fp-model option are "fpexcept.strict" and "fpexcept.ignore". In icc, we have > a separate option that can prevent speculation (equivalent to > "fpexcept.maytrap"). I think gcc's, -ftrapping-math has a similar function > (though the default may be reversed). I don't think we've talked about how > (or if) clang should ever get into the "fpexcept.maytrap" state. > > So for now, I think both arguments only need to support one of two states, > depending on the -fp-model arguments. In D62731#1620174 <https://reviews.llvm.org/D62731#1620174>, @andrew.w.kaylor wrote: > I'm not entirely caught up on this review. I've only read the most recent > comments, but I think I've got enough context to comment on the metadata > arguments. > > Based only on the fp-model command line options, the front end should only > ever use "round.dynamic" (for strict mode) or "round.tonearest" (where full > fenv access isn't permitted but we want to enable strict exception > semantics). There are some pragmas, which I believe are in some draft of a > standards document but not yet approved, which can declare any of the other > rounding modes, but I don't know that we have plans to implement those yet. > I'm also hoping that at some point we'll have a pass that finds calls to > fesetround() and changes the metadata argument when it can prove what the > rounding mode will be. > > For the fp exception argument, the only values that can be implied by the > -fp-model option are "fpexcept.strict" and "fpexcept.ignore". In icc, we have > a separate option that can prevent speculation (equivalent to > "fpexcept.maytrap"). I think gcc's, -ftrapping-math has a similar function > (though the default may be reversed). I don't think we've talked about how > (or if) clang should ever get into the "fpexcept.maytrap" state. > > So for now, I think both arguments only need to support one of two states, > depending on the -fp-model arguments. @andrew.w.kaylor Thanks Andy. Reminder -- in a private document you indicated to me that -fp-speculation=safe corresponds to the maytrap setting for the exception argument. This patch is implemented with those semantics. Repository: rL LLVM 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
