Re: [RFC] Add middle end hook for stack red zone size
Hello, it would be really nice if there can be reached an agreement here. The bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644 is open since 2008-12-27. As a user I don't care if it is fixed in the middle or back end or where ever. There are some duplicated bugs here, so this is not a but that hits you once in a thousand years. Kind regards, Sebastian -- Sebastian Huber, embedded brains GmbH Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany Phone : +49 89 18 90 80 79-6 Fax : +49 89 18 90 80 79-9 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: [RFC] Add middle end hook for stack red zone size
On Mon, Aug 01, 2011 at 11:44:04AM +0800, Jiangning Liu wrote: It's quite necessary to solve the general problem in middle-end rather than in back-end. That's what we disagree on. All back-ends but ARM are able to handle it right, why can't ARM too? The ABI rules for stack handling in the epilogues are simply too diverse and complex to be handled easily in the scheduler. Jakub
Re: [RFC] Add middle end hook for stack red zone size
On Mon, 1 Aug 2011, Jakub Jelinek wrote: On Mon, Aug 01, 2011 at 11:44:04AM +0800, Jiangning Liu wrote: It's quite necessary to solve the general problem in middle-end rather than in back-end. That's what we disagree on. All back-ends but ARM are able to handle it right, why can't ARM too? The ABI rules for stack handling in the epilogues are simply too diverse and complex to be handled easily in the scheduler. Given that the long-standing open bugs relating to scheduling and stack adjustments (30282, 38644) include issues for Power that do not yet appear to have been fixed, even if other back ends are able to handle it right they don't seem to do so at present. -- Joseph S. Myers jos...@codesourcery.com
RE: [RFC] Add middle end hook for stack red zone size
The answer is ARM can. However, if you look into the bugs PR30282 and PR38644, PR44199, you may find in history, there are several different cases in different ports reporting the similar failures, covering x86, PowerPC and ARM. You are right, they were all fixed in back-ends in the past, but we should fix the bug in a general way to make GCC infrastructure stronger, rather than fixing the problem target-by-target and case-by-case! If you further look into the back-end fixes in x86 and PowerPC, you may find they looks quite similar in back-ends. Thanks, -Jiangning -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Jakub Jelinek Sent: Monday, August 01, 2011 5:12 PM To: Jiangning Liu Cc: 'Joern Rennecke'; g...@gcc.gnu.org; gcc-patches@gcc.gnu.org; vmaka...@redhat.com; dje@gmail.com; Richard Henderson; Ramana Radhakrishnan; 'Ramana Radhakrishnan' Subject: Re: [RFC] Add middle end hook for stack red zone size On Mon, Aug 01, 2011 at 11:44:04AM +0800, Jiangning Liu wrote: It's quite necessary to solve the general problem in middle-end rather than in back-end. That's what we disagree on. All back-ends but ARM are able to handle it right, why can't ARM too? The ABI rules for stack handling in the epilogues are simply too diverse and complex to be handled easily in the scheduler. Jakub
Re: [RFC] Add middle end hook for stack red zone size
On 01/08/11 10:11, Jakub Jelinek wrote: On Mon, Aug 01, 2011 at 11:44:04AM +0800, Jiangning Liu wrote: It's quite necessary to solve the general problem in middle-end rather than in back-end. That's what we disagree on. All back-ends but ARM are able to handle it right, why can't ARM too? The ABI rules for stack handling in the epilogues are simply too diverse and complex to be handled easily in the scheduler. Because the vast majority of back-ends (ie those without red zones) shouldn't have to deal with this mess. This is something the MI code should be able to work out and deal with itself. Then the compiler will at least generate safe code, rather than randomly moving things about and allowing potentially unsafe writes/reads from beyond the allocated stack region. We should build the compiler defensively, but then allow for more aggressive optimizations to disable the defences when the back-end wants to take on the responsibility. Not the other way around. R.
Re: [RFC] Add middle end hook for stack red zone size
On Mon, Aug 01, 2011 at 06:14:27PM +0800, Jiangning Liu wrote: ARM. You are right, they were all fixed in back-ends in the past, but we should fix the bug in a general way to make GCC infrastructure stronger, rather than fixing the problem target-by-target and case-by-case! If you further look into the back-end fixes in x86 and PowerPC, you may find they looks quite similar in back-ends. Red zone is only one difficulty, your patch is e.g. completely ignoring existence of biased stack pointers (e.g. SPARC -m64 has them). Some targets have stack growing in opposite direction, etc. We have really a huge amount of very diverse ABIs and making the middle-end grok what is an invalid stack access is difficult. Jakub
RE: [RFC] Add middle end hook for stack red zone size
Hi Jakub, Appreciate for your valuable comments! I think SPARC V9 ABI doesn't have red zone defined, right? So stack_red_zone_size should be defined as zero by default, the scheduler would block moving memory accesses across stack adjustment no matter what the offset is. I don't see any risk here. Also, in my patch function *abs* is being used to avoid the opposite stack direction issue as you mentioned. Some people like you insist on the ABI diversity, and actually I agree with you on this. But part of the ABI definition is general for all targets. The point here is memory access beyond stack red zone should be avoided, which is the general part of ABI that compiler should guarantee. For this general part, middle end should take the responsibility. Thanks, -Jiangning -Original Message- From: Jakub Jelinek [mailto:ja...@redhat.com] Sent: Monday, August 01, 2011 6:31 PM To: Jiangning Liu Cc: 'Joern Rennecke'; g...@gcc.gnu.org; gcc-patches@gcc.gnu.org; vmaka...@redhat.com; dje@gmail.com; Richard Henderson; Ramana Radhakrishnan; 'Ramana Radhakrishnan' Subject: Re: [RFC] Add middle end hook for stack red zone size On Mon, Aug 01, 2011 at 06:14:27PM +0800, Jiangning Liu wrote: ARM. You are right, they were all fixed in back-ends in the past, but we should fix the bug in a general way to make GCC infrastructure stronger, rather than fixing the problem target-by-target and case-by-case! If you further look into the back-end fixes in x86 and PowerPC, you may find they looks quite similar in back-ends. Red zone is only one difficulty, your patch is e.g. completely ignoring existence of biased stack pointers (e.g. SPARC -m64 has them). Some targets have stack growing in opposite direction, etc. We have really a huge amount of very diverse ABIs and making the middle-end grok what is an invalid stack access is difficult. Jakub
RE: [RFC] Add middle end hook for stack red zone size
Joern, Thanks for your valuable feedback! This is only a RFC, and I will send out formal patch along with ChangLog later on. Basically, my patch is only to add new dependence in scheduler, and it only blocks some instruction movements, so it is NO RISK to compiler correctness. For whatever stack pointer changes you gave in different scenarios, the current code base should already work. My patch intends neither to replace old dependences, nor maximize the scheduler capability due to the existence of red zone in stack. It is only to block the memory access moving over stack pointer adjustment if distance is beyond red zone size, which is an OS requirement due to interruption existence. Stack adjustment in epilogue is a very general usage in stack frame. It's quite necessary to solve the general problem in middle-end rather than in back-end. Also, that old patch you attached is to solve the data dependence between two memory accesses, but stack pointer doesn't really have data dependence with memory access without using stack pointer, so they have different stories. Alternative solution of without adding blunt scheduling barrier is we insert an independent pass before scheduler to create RTL barrier by using the same interface stack_red_zone_size, but it would really be an over-design, if we add a new pass only for this *small* functionality. In my patch, *abs* of offset is being used, so you are right that it's possible to get false positive to be too conservative, but there won't exist false negative, because my code would only add new dependences. Since the compilation is based on function, it would be OK if red zone size varies due to different ABI. Could you please tell me exactly on what system being supported by GCC red zone size can be different for incoming and outgoing? And also how scheduler guarantee the correctness in current code base? Anyway, I don't think my patch will break the original solution. Thanks, -Jiangning -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Joern Rennecke Sent: Tuesday, July 26, 2011 10:33 AM To: Jiangning Liu Cc: g...@gcc.gnu.org; gcc-patches@gcc.gnu.org; vmaka...@redhat.com; dje@gmail.com; Richard Henderson; Ramana Radhakrishnan; 'Ramana Radhakrishnan' Subject: RE: [RFC] Add middle end hook for stack red zone size Quoting Jiangning Liu jiangning@arm.com: Hi, One month ago, I sent out this RFC to *gcc-patches* mail list, but I didn't receive any response yet. So I'm forwarding this mail to *gcc* mail list. Can anybody here really give feedback to me? Well, I couldn't approve any patch, but I can point out some issues with your patch. First, it's missing a ChangeLog, and you don't state how you have tested it. And regarding the code in sched_analyze_1, I think you'll get false positives with alloca, and false negatives when registers are involved to compute offsets or to restore the stack pointer from. FWIW, I think generally blunt scheduling barriers should be avoided, and instead the dependencies made visible to the scheduler. E.g., I've been working with another architecture with a redzone, where at -fno- omit-frame-pointer, the prologue can put pretend_args into the redzone, then after stack adjustment and frame allocation, these arguments are accessed via the frame pointer. With the attached patchlet, alias analysis works for this situation too, so no blunt scheduling block is required. Likewise, with stack adjustments, they should not affect scheduling in general, but be considered to clobber the part of the frame that is being exposed to interrupt writes either before or after the adjustment. At the moment, each port that wants to have such selective scheduling blockages has to define a stack_adjust pattern with a memory clobber in a parallel, with a memref that shows the high water mark of possible interrupt stack writes. Prima facia it would seem convenient if you only had to tell the middle-end about the redzone size, and it could figure out the implicit clobbers when the stack is changed. However, when a big stack adjustment is being made, or the stack is realigned, or restored from the frame pointer / another register where it was saved due to realignment, the adjustment is not so obvious. I'm not sure if you can actually create an robust interface that's simpler to use than putting the right memory clobber in the stack adjust pattern. Note also that the redzone size can vary from function to function depending on ABI-altering attributes, in particular for interrupt functions, which can also have different incoming and outgoing redzone sizes. Plus, you can have an NMI / reset handler which can use the stack like an ordinary address register.
RE: [RFC] Add middle end hook for stack red zone size
Hi, One month ago, I sent out this RFC to *gcc-patches* mail list, but I didn't receive any response yet. So I'm forwarding this mail to *gcc* mail list. Can anybody here really give feedback to me? Appreciate your help in advance! -Jiangning -Original Message- From: Ramana Radhakrishnan [mailto:ramana.radhakrish...@linaro.org] Sent: Tuesday, July 19, 2011 6:18 PM To: Jiangning Liu Cc: gcc-patches@gcc.gnu.org; vmaka...@redhat.com; dje@gmail.com; Richard Henderson; Ramana Radhakrishnan Subject: Re: [RFC] Add middle end hook for stack red zone size 2011/7/19 Jiangning Liu jiangning@arm.com: I see a lot of feedbacks on other posts, but mine is still with ZERO response in the past 3 weeks, so I'm wondering if I made any mistake in my process? Who can help me? It would be worth CC'ing the other relevant target maintainers as well to get some feedback since the patch touches ARM, x86 and Powerpc. I've added the maintainers for i386 and PPC to the CC list using the email addresses from the MAINTAINERS file. Thanks, Ramana Thanks, -Jiangning -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Jiangning Liu Sent: Tuesday, July 05, 2011 8:32 AM To: gcc-patches@gcc.gnu.org; rgue...@gcc.gnu.org Subject: RE: [RFC] Add middle end hook for stack red zone size PING... I just merged with the latest code base and generated new patch as attached. Thanks, -Jiangning -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- ow...@gcc.gnu.org] On Behalf Of Jiangning Liu Sent: 2011年6月28日 4:38 PM To: gcc-patches@gcc.gnu.org Subject: [RFC] Add middle end hook for stack red zone size This patch is to fix PR38644, which is a bug with long history about stack red zone access, and PR30282 is correlated. Originally red zone concept is not exposed to middle-end, and back-end uses special logic to add extra memory barrier RTL and help the correct dependence in middle-end. This way different back-ends must handle red zone problem by themselves. For example, X86 target introduced function ix86_using_red_zone() to judge red zone access, while POWER introduced offset_below_red_zone_p() to judge it. Note that they have different semantics, but the logic in caller sites of back-end uses them to decide whether adding memory barrier RTL or not. If back-end incorrectly handles this, bug would be introduced. Therefore, the correct method should be middle-end handles red zone related things to avoid the burden in different back-ends. To be specific for PR38644, this middle-end problem causes incorrect behavior for ARM target. This patch exposes red zone concept to middle-end by introducing a middle-end/back-end hook TARGET_STACK_RED_ZONE_SIZE defined in target.def, and by default its value is 0. Back-end may redefine this function to provide concrete red zone size according to specific ABI requirements. In middle end, scheduling dependence is modified by using this hook plus checking stack frame pointer adjustment instruction to decide whether memory references need to be all flushed out or not. In theory, if TARGET_STACK_RED_ZONE_SIZE is defined correctly, back-end would not be required to specially handle this scheduling dependence issue by introducing extra memory barrier RTL. In back-end, the following changes are made to define the hook, 1) For X86, TARGET_STACK_RED_ZONE_SIZE is redefined to be ix86_stack_red_zone_size() in i386.c, which is an newly introduced function. 2) For POWER, TARGET_STACK_RED_ZONE_SIZE is redefined to be rs6000_stack_red_zone_size() in rs6000.c, which is also a newly defined function. 3) For ARM and others, TARGET_STACK_RED_ZONE_SIZE is defined to be default_stack_red_zone_size in targhooks.c, and this function returns 0, which means ARM eabi and others don't support red zone access at all. In summary, the relationship between ABI and red zone access is like below, - | ARCH | ARM | X86 |POWER | others | |--|---|---|---|| |ABI | EABI | MS_64 | other | AIX | V4 || |--|---|---|---||--|| | RED ZONE | No | YES | No | YES | No | No | |--|---|---|---||--|| | RED ZONE SIZE| 0 | 128 | 0 |220/288 | 0 |0 | - Thanks, -Jiangning
RE: [RFC] Add middle end hook for stack red zone size
Quoting Jiangning Liu jiangning@arm.com: Hi, One month ago, I sent out this RFC to *gcc-patches* mail list, but I didn't receive any response yet. So I'm forwarding this mail to *gcc* mail list. Can anybody here really give feedback to me? Well, I couldn't approve any patch, but I can point out some issues with your patch. First, it's missing a ChangeLog, and you don't state how you have tested it. And regarding the code in sched_analyze_1, I think you'll get false positives with alloca, and false negatives when registers are involved to compute offsets or to restore the stack pointer from. FWIW, I think generally blunt scheduling barriers should be avoided, and instead the dependencies made visible to the scheduler. E.g., I've been working with another architecture with a redzone, where at -fno-omit-frame-pointer, the prologue can put pretend_args into the redzone, then after stack adjustment and frame allocation, these arguments are accessed via the frame pointer. With the attached patchlet, alias analysis works for this situation too, so no blunt scheduling block is required. Likewise, with stack adjustments, they should not affect scheduling in general, but be considered to clobber the part of the frame that is being exposed to interrupt writes either before or after the adjustment. At the moment, each port that wants to have such selective scheduling blockages has to define a stack_adjust pattern with a memory clobber in a parallel, with a memref that shows the high water mark of possible interrupt stack writes. Prima facia it would seem convenient if you only had to tell the middle-end about the redzone size, and it could figure out the implicit clobbers when the stack is changed. However, when a big stack adjustment is being made, or the stack is realigned, or restored from the frame pointer / another register where it was saved due to realignment, the adjustment is not so obvious. I'm not sure if you can actually create an robust interface that's simpler to use than putting the right memory clobber in the stack adjust pattern. Note also that the redzone size can vary from function to function depending on ABI-altering attributes, in particular for interrupt functions, which can also have different incoming and outgoing redzone sizes. Plus, you can have an NMI / reset handler which can use the stack like an ordinary address register. 2009-09-23 Joern Rennecke joern.renne...@embecosm.com * alias.c (base_alias_check): Allow for aliases between stack- and frame-pointer referenced memory. Index: alias.c === --- alias.c (revision 1646) +++ alias.c (revision 1647) @@ -1751,6 +1751,17 @@ base_alias_check (rtx x, rtx y, enum mac if (GET_CODE (x_base) != ADDRESS GET_CODE (y_base) != ADDRESS) return 0; + /* If both are stack references, one via the stack pointer, the other via + the frame pointer, there can be an alias. + E.g.: gcc.c-torture/execute/20041113-1.c -O3 -g */ + if (GET_CODE (x_base) == ADDRESS + (XEXP (x_base, 0) == stack_pointer_rtx + || XEXP (x_base, 0) == hard_frame_pointer_rtx) + GET_CODE (y_base) == ADDRESS + (XEXP (y_base, 0) == stack_pointer_rtx + || XEXP (y_base, 0) == hard_frame_pointer_rtx)) +return 1; + /* If one address is a stack reference there can be no alias: stack references using different base registers do not alias, a stack reference can not alias a parameter, and a stack reference
RE: [RFC] Add middle end hook for stack red zone size
PING... I just merged with the latest code base and generated new patch as attached. Thanks, -Jiangning -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- ow...@gcc.gnu.org] On Behalf Of Jiangning Liu Sent: 2011年6月28日 4:38 PM To: gcc-patches@gcc.gnu.org Subject: [RFC] Add middle end hook for stack red zone size This patch is to fix PR38644, which is a bug with long history about stack red zone access, and PR30282 is correlated. Originally red zone concept is not exposed to middle-end, and back-end uses special logic to add extra memory barrier RTL and help the correct dependence in middle-end. This way different back-ends must handle red zone problem by themselves. For example, X86 target introduced function ix86_using_red_zone() to judge red zone access, while POWER introduced offset_below_red_zone_p() to judge it. Note that they have different semantics, but the logic in caller sites of back-end uses them to decide whether adding memory barrier RTL or not. If back-end incorrectly handles this, bug would be introduced. Therefore, the correct method should be middle-end handles red zone related things to avoid the burden in different back-ends. To be specific for PR38644, this middle-end problem causes incorrect behavior for ARM target. This patch exposes red zone concept to middle-end by introducing a middle-end/back-end hook TARGET_STACK_RED_ZONE_SIZE defined in target.def, and by default its value is 0. Back-end may redefine this function to provide concrete red zone size according to specific ABI requirements. In middle end, scheduling dependence is modified by using this hook plus checking stack frame pointer adjustment instruction to decide whether memory references need to be all flushed out or not. In theory, if TARGET_STACK_RED_ZONE_SIZE is defined correctly, back-end would not be required to specially handle this scheduling dependence issue by introducing extra memory barrier RTL. In back-end, the following changes are made to define the hook, 1) For X86, TARGET_STACK_RED_ZONE_SIZE is redefined to be ix86_stack_red_zone_size() in i386.c, which is an newly introduced function. 2) For POWER, TARGET_STACK_RED_ZONE_SIZE is redefined to be rs6000_stack_red_zone_size() in rs6000.c, which is also a newly defined function. 3) For ARM and others, TARGET_STACK_RED_ZONE_SIZE is defined to be default_stack_red_zone_size in targhooks.c, and this function returns 0, which means ARM eabi and others don't support red zone access at all. In summary, the relationship between ABI and red zone access is like below, - | ARCH | ARM | X86 |POWER | others | |--|---|---|---|| |ABI | EABI | MS_64 | other | AIX | V4 || |--|---|---|---||--|| | RED ZONE | No | YES | No | YES | No | No | |--|---|---|---||--|| | RED ZONE SIZE| 0 | 128 | 0 |220/288 | 0 |0 | - Thanks, -Jiangning stack-red-zone-patch-38644-4.patch Description: Binary data
