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

[Richard Sandiford <richard.sandiford@arm.com>]

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 :-)

>> 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.
Most other things about an asm are target-dependent anyway.

> "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...
I think it would act like a noreturn call to an unknown function.
Output operands wouldn't make sense, and arguably clobbers wouldn't
either.

Thanks,
Richard

>> But either way, the general feeling seems to be that going straight to a
>> hard error is too harsh, since there's quite a bit of existing code that
>> has the clobber.  This patch implements the compromise discussed on IRC
>> yesterday of making it a -Wdeprecated warning instead.
>
> The patch looks fine to me.  Thanks!
>
>
> Segher