On Tue, Nov 5, 2024 at 3:49 PM Richard Biener
<richard.guent...@gmail.com> wrote:
>
> On Tue, Nov 5, 2024 at 2:47 PM Uros Bizjak <ubiz...@gmail.com> wrote:
> >
> > On Tue, Nov 5, 2024 at 12:19 PM Jakub Jelinek <ja...@redhat.com> wrote:
> > >
> > > On Tue, Nov 05, 2024 at 12:00:24PM +0100, Uros Bizjak wrote:
> > > > On Tue, Nov 5, 2024 at 11:43 AM Andreas Schwab <sch...@linux-m68k.org>
> > > > wrote:
> > > > >
> > > > > On Nov 05 2024, Uros Bizjak wrote:
> > > > >
> > > > > > But what is the non-deprecated way to communicate the fact that SP
> > > > > > changes, and possibly clobbers stack in the asm to the compiler?
> > > > >
> > > > > Since an asm statement is not allowed to change SP there is no need
> > > > > for
> > > > > that.
> > > >
> > > > asm volatile ("pushfq; popfq %0" : "=r"(x));
> > > >
> > > > doesn't change SP at any sequence point, doesn't clobber the function
> > > > frame, but the function using it shouldn't create redzone. How to
> > > > communicate this to the compiler?
> > >
> > > One possibility would be make __attribute__((target ("no-red-zone")))
> > > working (I think currently the option isn't TargetSave or isn't listed
> > > somewhere, so it doesn't work).
> >
> > This won't work if we have a macro that is used in several functions.
> > We will have to manually add the above attribute to all functions that
> > inline the macro with redzone clobbering asm.
> >
> > > And the other one is IMHO making it explicit that it clobbers the red
> > > zone,
> > > so "redzone" or "red-zone" clobber (or some other word, but can't be
> > > easily
> > > stack-below-sp because we have hppa with stack growing in the wrong
> > > direction).
> >
> > We would have to define a memory clobber that would correspond to
> > redzone and attach it to the asm parallel RTX, perhaps:
> >
> > (clobber (mem:BLK (reg:DI sp)))
> >
> > that would ultimately clear "crtl->is_leaf" when detected.
>
> Maybe never make functions having any volatile asm() "leaf"? Thus
> require 'volatile' to be present - aka the asm has side-effects that
> are not fully encoded in the constraints.
I think this would work!
Although this *might* be somehow a big hammer approach, disabling a
redzone optimization for leaf function with volatile asm is not that
problematic. Nowadays, small functions are inlined, so setting up and
tearing down a frame is not that performance critical.
And as you said - conceptually volatile covers "unspecified" side
effects. asm volatile might change stack (not stack pointer!) as a
side effect, so function with asm volatile can not be leaf.
We can document that any stack manipulation inside asm requires asm to
be volatile, that would also satisfy PR117311.
Uros.
