[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package

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

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

--- Comment #12 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #11)
> > > but how are users supposed to know whether
> > > -fno-omit-frame-pointer is in effect or not?  I've looked and there is no
> > > pre-defined macro a user could check.
> > That might be a useful thing to have, but if the programmer has no control
> > over the build flags (i.e. cannot require/force -fomit-frame-pointer) then I
> > think the asm has to take care to save and restore the frame pointer itself.
> > 
> > Dropping "31" from the asm means that the asm must preserve the register. 
> > Things will go badly if the asm doesn't do that.
> 
> So r31 which we use as our frame-pointer reg is a non-volatile/callee saved
> register, so it must be saved, but I guess they (greenlet) cannot use the
> method of mentioning it in the asm clobber list to perform that.
I was thinking of just the asm in isolation, rather than its effect on the
containing function's callee-save set.

If you have:

  asm volatile ("…");

then GCC expects r31 after the asm to equal r31 before the asm, regardless of
the -fomit-frame-pointer setting.  If the asm is:

  asm volatile ("li r31,0");

(sorry, I've forgotten the actual Power asm :)) then things will go wrong if
GCC tries to use r31 after the asm.

If the asm clobbers r31 then it must mention it in the clobber list.  As things
stand, it's not possible to mention r31 in the clobber list if
-fno-omit-frame-pointer.  This means that the only option for code that wants
to support -fno-omit-frame-pointer is to make the asm's contents preserve r31,
using an explicit save and restore if necessary.

And that kind-of makes sense.  If an asm clobbers the frame pointer, that
removes GCC's main option for restoring data after the asm.  A lot of other
clobbers would be handled by loading data relative to the frame pointer.  If
the frame pointer itself has gone then things get tricky.