From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8103 invoked by alias); 21 Jul 2010 17:36:46 -0000 Received: (qmail 8090 invoked by uid 22791); 21 Jul 2010 17:36:44 -0000 X-SWARE-Spam-Status: No, hits=-5.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 21 Jul 2010 17:36:38 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o6LHaaWI003649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Jul 2010 13:36:37 -0400 Received: from anchor.twiddle.home (vpn-230-204.phx2.redhat.com [10.3.230.204]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o6LHaaFO019407; Wed, 21 Jul 2010 13:36:36 -0400 Message-ID: <4C473024.3030901@redhat.com> Date: Wed, 21 Jul 2010 17:36:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Thunderbird/3.0.5 MIME-Version: 1.0 To: Kai Tietz CC: GCC Patches , NightStrike Subject: Re: [RFA patch i386]: Prepare x64 prologue using positive offsets for frame-pointer References: <4C4629D2.1050303@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg01661.txt.bz2 On 07/21/2010 12:43 AM, Kai Tietz wrote: > 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. http://software.intel.com/en-us/forums/showthread.php?t=72496 This says that the MSABI for AVX will consider the high parts of the YMM registers volatile. Which means that for the purpose of the prologue we only need to save the low 16 bytes. Which means that we can arrange the frame like so: [ return addr ] <-- entry sp [ saved int regs ] [ saved xmm regs ] <-- fp [ stack re-alignment ] [ local stack frame ] <-- sp Here, fp is not at the bottom of the stack, but it is below all of the saved registers, which means that they're all at positive offsets from fp, which is the only real requirement of SEH. Also, the local stack frame is aligned, which allows aligned spilling of YMM registers or other over- aligned data. r~