Re: [PATCH] [RFC] PR target/52813 and target/11807

[Segher Boessenkool <segher@kernel.crashing.org>]

On Thu, Jan 10, 2019 at 09:23:27PM +0000, Richard Sandiford wrote:
> Segher Boessenkool <segher@kernel.crashing.org> writes:
> > On Tue, Jan 08, 2019 at 12:03:06PM +0000, Richard Sandiford wrote:
> >> Bernd Edlinger <bernd.edlinger@hotmail.de> writes:
> >> > Meanwhile I found out, that the stack clobber has only been ignored up to
> >> > gcc-5 (at least with lra targets, not really sure about reload targets).
> >> > From gcc-6 on, with the exception of PR arm/77904 which was a regression due
> >> > to the underlying lra change, but fixed later, and back-ported to gcc-6.3.0,
> >> > this works for all targets I tried so far.
> >> >
> >> > To me, it starts to look like a rather unique and useful feature, that I would
> >> > like to keep working.
> >> 
> >> Not sure what you mean by "unique".  But forcing a frame is a bit of
> >> a slippery concept.  Force it where?  For the asm only, or the whole
> >> function?  This depends on optimisation and hasn't been consistent
> >> across GCC versions, since it depends on the shrink-wrapping
> >> optimisation.  (There was a similar controversy a while ago about
> >> to what extent -fno-omit-frame-pointer should "force a frame".)
> >
> > It's not forcing a frame currently: it's just setting frame_pointer_needed.
> > Whatever happens from that is the target's business.
> 
> Do you mean the asm clobber or -fno-omit-frame-pointer?  If the option,
> then yeah, and that was exactly what was controversial :-)

I meant the asm clobber.  LRA sets frame_pointer_needed to 1 because the
stack pointer is clobbered, on many targets anyway:

          /* If we modify the source of an elimination rule, disable
             it.  Do the same if it is the destination and not the
             hard frame register.  */
          for (ep = reg_eliminate;
               ep < &reg_eliminate[NUM_ELIMINABLE_REGS];
               ep++)
            if (ep->from_rtx == XEXP (x, 0)
                || (ep->to_rtx == XEXP (x, 0)
                    && ep->to_rtx != hard_frame_pointer_rtx))
              setup_can_eliminate (ep, false);

and setup_can_eliminate has

  if (! value
      && ep->from == FRAME_POINTER_REGNUM && ep->to == STACK_POINTER_REGNUM)
    frame_pointer_needed = 1;

> >> The effect on the redzone seems like something that should be specified
> >> explicitly rather than as an (accidental?) side effect of listing the
> >> sp in the clobber list.  Maybe this would be another use for the "asm
> >> attributes" proposal.  "noreturn" was another attribute suggested on
> >> IRC yesterday.
> >
> > Redzone is target-dependent.
> 
> Right.  Target-dependent asm attributes wouldn't be a problem though.

It's harder to document, which means it is harder to get right (and get
people to _use_ it correctly), as well.

> Most other things about an asm are target-dependent anyway.

Very true.

> > "noreturn"...  What would that mean, *exactly*?  It cannot execute any
> > code the compiler can see, so such asm is better off as real asm anyway
> > (not inline asm).
> 
> "Exactly" is a strong word, and this wasn't my proposal, but...

"Exactly", as in, "please do enough hand-waving to cover all available
space" ;-)

There are many details that aren't quite obvious, but they do matter for
how usable and useful this extension would be.

> I think it would act like a noreturn call to an unknown function.

Except it won't behave like a call otherwise (on Power all calls force a
stack frame, for example; and on all targets noreturn calls do the same
currently I think?)

> Output operands wouldn't make sense, and arguably clobbers wouldn't
> either.

Yeah.


Segher