[Bug target/102783] [powerpc] FPSCR manipulations cannot be relied upon

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to joseph@codesourcery.com from comment #9)
> On Tue, 19 Oct 2021, segher at gcc dot gnu.org via Gcc-bugs wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783
> > 
> > --- Comment #8 from Segher Boessenkool <segher at gcc dot gnu.org> ---
> > (In reply to joseph@codesourcery.com from comment #6)
> > > Generically (and if the command-line options are such that floating-point 
> > > control / status bits are to be respected by optimizations), *any* 
> > > function call might access or modify floating-point control and status 
> > > bits, subject to e.g. const functions not being able to access them, pure 
> > > functions not being able to modify them, functions whose body is known 
> > > having properties based on analysis of that body, built-in functions 
> > > having semantics based on what the compiler knows about those functions.  
> > 
> > If FENV_ACCESS is OFF most of those things can be ignored as well.  But
> > FENV_ACCESS is much too blunt a hammer for most of our uses.
> 
> My recent discussions with Roger Sayle 
> <https://gcc.gnu.org/pipermail/gcc-patches/2021-September/thread.
> html#580252>, 
> and bug 54192 as referenced therein, may be helpful for more details of 
> how FENV_ACCESS could be split up.  (At present we have -ftrapping-math, 
> on by default, and -frounding-math, off by default.  I suspect that if 
> -ftrapping-math really restricted optimizations enough to avoid all 
> problematic code reordering / removal in the presence of function calls 
> possibly reading and writing exception flags, it would actually inhibit 
> optimization more than a full implementation of -frounding-math would: a 
> full -frounding-math only means that arithmetic *reads* the rounding mode, 
> whereas a full -ftrapping-math means that arithmetic *writes* to the 
> exception flags.)

But one interesting detail is that those writes can be re-ordered when
they are not (synchronously) observed since the exception flags as
produced by arithmetic are "sticky".  That makes mapping their dataflow
to SSA not very precise, you'd have to make arithmetic produce flags
and merge them at use points.

Anyway, I think we can reach a good enough implementation without actually
implementing any data flow by simply restricting what we do to stmts.
It will of course require manual intervention in passes that can break
things rather than having the restriction being visible by data flow that's
checked anyway.