[PATCH] D62731: [RFC] Add support for options -fp-model= and -fp-speculation= : specify floating point behavior

Melanie Blower via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Aug 9 08:36:13 PDT 2019


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





More information about the cfe-commits mailing list