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
