From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27807 invoked by alias); 1 Aug 2011 03:44:49 -0000 Received: (qmail 27782 invoked by uid 22791); 1 Aug 2011 03:44:46 -0000 X-SWARE-Spam-Status: No, hits=-2.1 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; Mon, 01 Aug 2011 03:44:28 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Mon, 01 Aug 2011 04:44:24 +0100 Received: from jiangningsh02 ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Aug 2011 04:44:21 +0100 From: "Jiangning Liu" To: "'Joern Rennecke'" Cc: , , , , "Richard Henderson" , "Ramana Radhakrishnan" , "'Ramana Radhakrishnan'" References: <4e255312.0a852b0a.528d.6933SMTPIN_ADDED@mx.google.com> <001e01cc4b33$6d3818f0$47a84ad0$@liu@arm.com> <20110725223319.petrcv01csccs44s-nzlynne@webmail.spamcop.net> In-Reply-To: <20110725223319.petrcv01csccs44s-nzlynne@webmail.spamcop.net> Subject: RE: [RFC] Add middle end hook for stack red zone size Date: Mon, 01 Aug 2011 03:44:00 -0000 Message-ID: <000001cc4ffd$48680ac0$d9382040$@liu@arm.com> MIME-Version: 1.0 X-MC-Unique: 111080104442400201 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-08/txt/msg00000.txt.bz2 Joern, Thanks for your valuable feedback! This is only a RFC, and I will send out = formal patch along with ChangLog later on.=20 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 correctnes= s. 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 st= ack pointer adjustment if distance is beyond red zone size, which is an OS = requirement due to interruption existence.=20 Stack adjustment in epilogue is a very general usage in stack frame. It's q= uite necessary to solve the general problem in middle-end rather than in ba= ck-end. Also, that old patch you attached is to solve the data dependence b= etween two memory accesses, but stack pointer doesn't really have data depe= ndence with memory access without using stack pointer, so they have differe= nt 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 ov= er-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 poss= ible to get false positive to be too conservative, but there won't exist fa= lse negative, because my code would only add new dependences.=20 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 syst= em being supported by GCC red zone size can be different for incoming and o= utgoing? And also how scheduler guarantee the correctness in current code b= ase? Anyway, I don't think my patch will break the original solution. Thanks, -Jiangning > -----Original Message----- > From: gcc-patches-owner@gcc.gnu.org [mailto:gcc-patches-owner@gcc.gnu.org] > On Behalf Of Joern Rennecke > Sent: Tuesday, July 26, 2011 10:33 AM > To: Jiangning Liu > Cc: gcc@gcc.gnu.org; gcc-patches@gcc.gnu.org; vmakarov@redhat.com; > dje.gcc@gmail.com; Richard Henderson; Ramana Radhakrishnan; 'Ramana > Radhakrishnan' > Subject: RE: [RFC] Add middle end hook for stack red zone size >=20 > Quoting Jiangning Liu : >=20 > > 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? >=20 > Well, I couldn't approve any patch, but I can point out some issues with = your patch. >=20 > 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 posit= ives with > alloca, and false negatives when registers are involved to compute offset= s or to > restore the stack pointer from. >=20 > 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 a= t -fno- > omit-frame-pointer, the prologue can put pretend_args into the redzone, t= hen after > stack adjustment and frame allocation, these arguments are accessed via t= he frame > pointer. >=20 > With the attached patchlet, alias analysis works for this situation too, = so no blunt > scheduling block is required. >=20 > Likewise, with stack adjustments, they should not affect scheduling in ge= neral, but > be considered to clobber the part of the frame that is being exposed to i= nterrupt > writes either before or after the adjustment. > At the moment, each port that wants to have such selective scheduling blo= ckages > 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-e= nd 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 stac= k 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 th= e right > memory clobber in the stack adjust pattern. Note also that the redzone s= ize can > vary from function to function depending on ABI-altering attributes, in p= articular > for interrupt functions, which can also have different incoming and outgo= ing > redzone sizes. Plus, you can have an NMI / reset handler which can use t= he stack > like an ordinary address register.