W.r.t. the new attribute that we could apply to the FP atomic methods in
libstdc++ (something like `[[__gnu__::__ignore_fenv__]]` discussed in
earlier emails):
I believe that the existing semantics of `-ffast-math` (i.e. all of its
sub-flags) are not enough to specify "may execute in a different FP
environment". Reasons I think this are below.
I'd like to invite corrections on this reasoning.
If no corrections, I suspect the best approach would be to add a new
sub-flag for `-ffast-math` (e.g. `-fignore-fenv`) that directly
specifies what is needed for these FP atomic methods. That would mean
that someone using `-ffast-math` on general code that includes a FP CAS
loop might get the AArch64 LSFE instructions. Would people agree that
sounds best?
In this approach the new attribute of `__gnu__::__ignore_fenv__` would
correspond to something very similar to applying this flag to the
relevant function.
Reasons I think existing `-ffast-math` not sufficient:
1) -fno-trapping-math says that invalid operations do not generate
runtime exceptions. This is necessary, but says nothing about
allowing us to skip setting status flags in the FP environment.
- Hence doesn't seem to give us everything we need.
2) -fno-rounding-math allows optimisations that assume round-to-nearest.
This seems to not be sufficient for the fetch_add semantics.
libstdc++ FP atomics semantics say can act as if in different FP
environment, which I would expect means a hardware implementation can
choose whatever FP rounding mode (doesn't have to be the default
one).
3) No -ffast-math flag mentions anything about what NaN is generated --
These methods need to allow choosing something different, and the
AArch64 implementation actually does change what kind of NaN's are
produced.
Cheers,
Matthew
On 4/30/26 07:19, Richard Biener wrote:
External email: Use caution opening links or attachments
On Wed, 29 Apr 2026, Jonathan Wakely wrote:
On Wed, 29 Apr 2026 at 14:49, Matthew Malcomson <[email protected]> wrote:
Things I'm not quite certain on:
- Is it viable to annotate a function in a libstdc++ header with some
new attribute that says "can operate in different FP environment"?
That seems OK to me. The __has_cpp_attribute check should give the
right answer for that new attribute (e.g. true on aarch64 and false
elsewhere for now) so that we can use:
#if __has_cpp_attribute(__gnu__::__ignores_fenv__)
[[__gnu__::__ignore_fenv__]]
#endif
Note that the middle-end can handle these aspects only on per-function
granularity and in the case of FP rounding and exceptions you'd
specify -fno-trapping-math -fno-rounding-math. I'm unsure whether,
with a loop, there might be effets of signed zeros that are
effectively ignored or not?
Specifying -fno-trapping-math -fno-rounding-math can have an effect
on inlining of and into the annotated function.
Richard.
