This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


r~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]