Hello... Can *anybody* give me comments on this bug fix? Our customers have been complaining about this bug with long history.
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? 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
