RE: [PATCH] Fix stack red zone bug (PR38644)

["Jiangning Liu" <jiangning dot liu at arm dot com>]

> -----Original Message-----
> From: Richard Henderson [mailto:rth@redhat.com]
> Sent: Saturday, October 01, 2011 3:05 AM
> To: Jiangning Liu
> Cc: 'Jakub Jelinek'; 'Richard Guenther'; Andrew Pinski; gcc-
> patches@gcc.gnu.org
> Subject: Re: [PATCH] Fix stack red zone bug (PR38644)
> 
> On 09/29/2011 06:13 PM, Jiangning Liu wrote:
> >
> >
> >> -----Original Message-----
> >> From: Jakub Jelinek [mailto:jakub@redhat.com]
> >> Sent: Thursday, September 29, 2011 6:14 PM
> >> To: Jiangning Liu
> >> Cc: 'Richard Guenther'; Andrew Pinski; gcc-patches@gcc.gnu.org
> >> Subject: Re: [PATCH] Fix stack red zone bug (PR38644)
> >>
> >> On Thu, Sep 29, 2011 at 06:08:50PM +0800, Jiangning Liu wrote:
> >>> As far as I know different back-ends are implementing different
> >>> prologue/epilogue in GCC. If one day this part can be refined and
> >> abstracted
> >>> as well, I would say solving this stack-red-zone problem in shared
> >>> prologue/epilogue code would be a perfect solution, and barrier can
> >> be
> >>> inserted there.
> >>>
> >>> I'm not saying you are wrong on keeping scheduler using a pure
> >> barrier
> >>> interface. From engineering point of view, I only feel my proposal
> is
> >> so far
> >>> so good, because this patch at least solve the problem for all
> >> targets in a
> >>> quite simple way. Maybe it can be improved in future based on this.
> >>
> >> But you don't want to listen about any other alternative, other
> >> backends are
> >> happy with being able to put the best kind of barrier at the best
> spot
> >> in the epilogue and don't need a "generic" solution which won't
> model
> >> very
> >> well the target diversity anyway.
> >
> > Jakub,
> >
> > Appreciate for your attention on this issue,
> >
> > 1) Can you clarify who are the "others back-ends"? Does it cover most
> of the
> > back-ends being supported by GCC right now?
> 
> Your red-stack barrier issue is *exactly* the same as the frame pointer
> barrier issue, which affects many backends.
> 
> That is, if the frame pointer is initialized before the local stack
> frame
> is allocated, then one has to add a barrier such that memory references
> based on the frame pointer are not scheduled before the local stack
> frame
> allocation.
> 
> One example of this is in the i386 port, where the prologue looks like
> 
> 	push	%ebp
> 	mov	%esp, %ebp
> 	sub	$frame, %esp
> 
> The rtl we emit for that subtraction looks like
> 
> (define_insn "pro_epilogue_adjust_stack_<mode>_add"
>   [(set (match_operand:P 0 "register_operand" "=r,r")
>         (plus:P (match_operand:P 1 "register_operand" "0,r")
>                 (match_operand:P 2 "<nonmemory_operand>" "r<i>,l<i>")))
>    (clobber (reg:CC FLAGS_REG))
>    (clobber (mem:BLK (scratch)))]
> 
> Note the final clobber, which is a memory scheduling barrier.
> 
> Other targets use similar tricks.  For instance arm "stack_tie".
> 
> Honestly, I've found nothing convincing throughout this thread that
> suggests to me that this problem should be handled generically.
> 

Richard H.,

Thanks for your explanation by giving an example in x86. 

The key is if possible, fixing it in middle end can benefit all ports
directly and avoid bug fixing burden in back-ends, rather than fix this
problem port by port.

Actually now the debating here is whether memory barrier is properly
modeling through whole GCC rather than a single component, because my
current understanding is scheduler is not the only component using memory
barrier.

Thanks,
-Jiangning

> 
> r~