From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5592 invoked by alias); 21 Jul 2010 07:43:51 -0000 Received: (qmail 5576 invoked by uid 22791); 21 Jul 2010 07:43:50 -0000 X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mail-bw0-f47.google.com (HELO mail-bw0-f47.google.com) (209.85.214.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 21 Jul 2010 07:43:44 +0000 Received: by bwz10 with SMTP id 10so4554324bwz.20 for ; Wed, 21 Jul 2010 00:43:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.126.29 with SMTP id a29mr638791bks.59.1279698221591; Wed, 21 Jul 2010 00:43:41 -0700 (PDT) Received: by 10.204.57.197 with HTTP; Wed, 21 Jul 2010 00:43:41 -0700 (PDT) In-Reply-To: <4C4629D2.1050303@redhat.com> References: <4C4629D2.1050303@redhat.com> Date: Wed, 21 Jul 2010 07:43:00 -0000 Message-ID: Subject: Re: [RFA patch i386]: Prepare x64 prologue using positive offsets for frame-pointer From: Kai Tietz To: Richard Henderson Cc: GCC Patches , NightStrike Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2010-07/txt/msg01622.txt.bz2 2010/7/21 Richard Henderson : > On 07/18/2010 03:42 AM, Kai Tietz wrote: >> +mframe-x64 >> +Target Report Var(flag_framex64) Init(0) >> +Set the frame-pointer to the stack location at the end of prologue for = 64-bit. > > Modulo testing purposes, a command-line switch makes no sense. =A0We'll w= ant to > key this off SEH enabled, or at least TARGET_64BIT_MS_ABI. Well, I agree here, as this frame-layout is required for -mseh. I added this as general option to have a chance to not enable it by default. That this layout is dependent just to TARGET_64BIT_MS_ABI isn't correct, as this macro checks for function ABI, which is for target unwind-emitting (which has to be active for all calling conventions) not suiteable. A check of (TARGET_64BIT && ix86_abi =3D=3D MS_ABI) fits better IMHO. > The state of ix86_expand_prologue/epilogue is... what's a kind word... ch= aotic? > This isn't your fault, but your patch doesn't help either. =A0It's extrem= ely > difficult to tell if your patch is correct. =A0I'm pretty sure it isn't c= orrect > for any case of stack re-alignment, for instance. Well, as x64 ABI aligns stack (beside leaf-functions) to 16-bytes, there is for default nothing to fear. There is one nit about AVX register store, which leads to a stack-realignment of 32-byte, that would fail. The issue is that x64 ABI doesn't specifies anything about new AVX (well the HW isn't even on market AFAIK). I see here two possible ways to address this. a) Sorry the use of AVX and x64 with SEH unwind-information. Or b) save initial stack-position in stack-frame at the realignment is performed. > I spent an hour or three attempting to tidy up these functions and handle= the > frame pointer at the bottom of the frame. =A0I have some ideas now for ho= w to > clean things up, but I think they'll really need to be staged in in phase= s. > One big patch would simply be too unwieldy. Excellent. > I'll work on this cleanup over the next couple of days. > > > > r~ > Regards, Kai --=20 |=A0 (\_/) This is Bunny. Copy and paste | (=3D'.'=3D) Bunny into your signature to help | (")_(") him gain world domination