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

[segher at gcc dot gnu.org]

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

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-10-15
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #3 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Confirmed.

This is about the control part.  The status part has similar issues as well
but needs opposite ordering; we do not have any ordering right now, that is
the problem.

We have the same issues for vectors with the VSCR.  That one has only one
status bit: SAT, for saturation, and we set that explicitly in all insns that
do set it.  All of those are unusual, done via builtins, etc.  We model a VSCR
register just for this.  It also has one control bit: NJ, "non-java", it
disables strict IEEE arithmetic, which was useful for improved performance on
old cores.  We do not actually order setting that relative to insns that use
that control bit, but I have never actually seen anything set that bit, so the
issue does not practically exist there.

But for FP we need to order setting the control bits relative to any FP
computational insn, and reading the status bits as well.  There currently is
no way in GCC to say this.  It might be best to have an hook to say what
control bits there are, what insns care about which control bits, and what
insns set each of those bits.  And similar for status bits.

Does this sound generic enough, does it serve the needs of all targets?