From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28998 invoked by alias); 26 Jul 2011 01:29:57 -0000 Received: (qmail 28703 invoked by uid 22791); 26 Jul 2011 01:29:54 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,MSGID_MULTIPLE_AT,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from service87.mimecast.com (HELO service87.mimecast.com) (94.185.240.25) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Tue, 26 Jul 2011 01:29:27 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Tue, 26 Jul 2011 02:29:23 +0100 Received: from jiangningsh02 ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jul 2011 02:29:20 +0100 From: "Jiangning Liu" To: Cc: , , , "Richard Henderson" , "Ramana Radhakrishnan" , "'Ramana Radhakrishnan'" References: <4e255312.0a852b0a.528d.6933SMTPIN_ADDED@mx.google.com> In-Reply-To: Subject: RE: [RFC] Add middle end hook for stack red zone size Date: Tue, 26 Jul 2011 01:31:00 -0000 Message-ID: <001e01cc4b33$6d3818f0$47a84ad0$@liu@arm.com> MIME-Version: 1.0 X-MC-Unique: 111072602292300501 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-07/txt/msg00460.txt.bz2 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.radhakrishnan@linaro.org]=20 Sent: Tuesday, July 19, 2011 6:18 PM To: Jiangning Liu Cc: gcc-patches@gcc.gnu.org; vmakarov@redhat.com; dje.gcc@gmail.com; Richar= d Henderson; Ramana Radhakrishnan Subject: Re: [RFC] Add middle end hook for stack red zone size 2011/7/19 Jiangning Liu : > > 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-owner@gcc.gnu.org [mailto:gcc-patches-owner@gcc.gnu.org] > On Behalf Of Jiangning Liu > Sent: Tuesday, July 05, 2011 8:32 AM > To: gcc-patches@gcc.gnu.org; rguenth@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 attach= ed. > > Thanks, > -Jiangning > >> -----Original Message----- >> From: gcc-patches-owner@gcc.gnu.org [mailto:gcc-patches- >> owner@gcc.gnu.org] On Behalf Of Jiangning Liu >> Sent: 2011=E5=B9=B46=E6=9C=8828=E6=97=A5 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 > > > >