From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 707 invoked by alias); 2 Aug 2011 04:46:10 -0000 Received: (qmail 689 invoked by uid 22791); 2 Aug 2011 04:46:08 -0000 X-SWARE-Spam-Status: No, hits=-2.3 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, 02 Aug 2011 04:45:53 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Tue, 02 Aug 2011 05:45:48 +0100 Received: from jiangningsh02 ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Aug 2011 05:45:45 +0100 From: "Jiangning Liu" To: "'Jakub Jelinek'" Cc: "'Joern Rennecke'" , , , , , "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> <000001cc4ffd$48680ac0$d9382040$@liu@arm.com> <20110801091151.GD27949@sunsite.ms.mff.cuni.cz> <000a01cc5033$cf0817b0$6d184710$@liu@arm.com> <20110801103047.GX2687@tyan-ft48-01.lab.bos.redhat.com> In-Reply-To: <20110801103047.GX2687@tyan-ft48-01.lab.bos.redhat.com> Subject: RE: [RFC] Add middle end hook for stack red zone size Date: Tue, 02 Aug 2011 04:46:00 -0000 Message-ID: <000c01cc50cf$06fcb9a0$14f62ce0$@liu@arm.com> MIME-Version: 1.0 X-MC-Unique: 111080205454800501 Content-Type: text/plain; charset=WINDOWS-1252 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/msg00031.txt.bz2 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:jakub@redhat.com] > Sent: Monday, August 01, 2011 6:31 PM > To: Jiangning Liu > Cc: 'Joern Rennecke'; 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 > 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. > > >=20 > 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. >=20 > Jakub