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

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

Segher Boessenkool <segher@kernel.crashing.org> writes:
> On Mon, Dec 17, 2018 at 11:47:42AM +0000, Richard Sandiford wrote:
>> Dimitar Dimitrov <dimitar@dinux.eu> writes:
>> > On Sun, Dec 16 2018 at 14:36:26 EET Bernd Edlinger wrote:
>> >> Hi,
>> >> 
>> >> if I understood that right, then clobbering sp is and has always been
>> >> ignored.
>> 
>> PR77904 was about the clobber not being ignored, so the behaviour
>> hasn't been consistent.
>> 
>> I'm also not sure it was always ignored in recent sources.  The clobber
>> does get added to the associated rtl insn, and it'd be surprising if
>> that never had an effect.
>
> Yes, you will usually get a frame pointer.  My point was that the epilogue
> will restore your stack pointer both with and without the asm clobber.

I'm not confident that's the only effect though.

Also, we didn't use a frame in PR77904, and using a frame would have
been the wrong thing to do.

>> I don't think there's a good reason to treat this differently from the
>> preexisting PIC register error.  If the argument for making it a warning
>> rather than an error is that the asm might happen to work by accident,
>> then the same is true for the PIC register.
>
> Yes.  As well as quite a few more registers, many of those specific to
> the target.  And there are many more things you can do terribly wrong in
> inline assembler, of course, most of which we can never detect.

Right.  And I don't think anyone's suggesting GCC can detect everything.
It can only police the things it knows about, which include the input,
output and clobber clauses.

What makes the PIC register and sp worth special attention is that
changing their values would in general invalidate other code that GCC
generates itself.  It's not just about whether the asm has the effect
the author wanted (whatever that was).

FWIW, I don't think we should go on a proactive hunt for other registers
to complain about.

Thanks,
Richard