From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25256 invoked by alias); 11 Jun 2008 14:49:59 -0000 Received: (qmail 25247 invoked by uid 22791); 11 Jun 2008 14:49:58 -0000 X-Spam-Check-By: sourceware.org Received: from py-out-1112.google.com (HELO py-out-1112.google.com) (64.233.166.182) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 11 Jun 2008 14:49:38 +0000 Received: by py-out-1112.google.com with SMTP id d37so1336859pye.29 for ; Wed, 11 Jun 2008 07:49:36 -0700 (PDT) Received: by 10.115.89.1 with SMTP id r1mr6663577wal.116.1213195771459; Wed, 11 Jun 2008 07:49:31 -0700 (PDT) Received: from lucon.org ( [76.252.222.99]) by mx.google.com with ESMTPS id z20sm18957790pod.11.2008.06.11.07.49.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Jun 2008 07:49:24 -0700 (PDT) Received: by lucon.org (Postfix, from userid 500) id CA8379801BE; Wed, 11 Jun 2008 07:49:12 -0700 (PDT) Date: Wed, 11 Jun 2008 14:49:00 -0000 To: Jan Hubicka Cc: Jakub Jelinek , Jan Hubicka , discuss@x86-64.org, GCC , "Girkar, Milind" , "Dmitriev, Serguei N" , "Kreitzer, David L" Subject: Re: RFC: Extend x86-64 psABI for 256bit AVX register Message-ID: <20080611144912.GA7049@lucon.org> References: <20080606135026.GA14877@lucon.org> <20080606142813.GA18621@lucon.org> <20080609144054.GA13869@atrey.karlin.mff.cuni.cz> <20080610113921.GX3726@sunsite.mff.cuni.cz> <20080610113220.GD13869@atrey.karlin.mff.cuni.cz> <6dc9ffc80806100647p2c199dbcj5a3650ad97837c63@mail.gmail.com> <20080610145014.GH17032@kam.mff.cuni.cz> <20080610151122.GZ3726@sunsite.mff.cuni.cz> <6dc9ffc80806100841s291c8491g16767b36aac9a796@mail.gmail.com> <20080610154857.GE20774@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080610154857.GE20774@kam.mff.cuni.cz> User-Agent: Mutt/1.5.17 (2007-11-01) From: "H.J. Lu" 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: 2008-06/txt/msg00271.txt.bz2 On Tue, Jun 10, 2008 at 05:48:57PM +0200, Jan Hubicka wrote: > > On Tue, Jun 10, 2008 at 8:11 AM, Jakub Jelinek wrote: > > > On Tue, Jun 10, 2008 at 04:50:14PM +0200, Jan Hubicka wrote: > > >> 1) make __m256 passed on stack on variadic functions and in registers > > >> otherwse. Then we don't need to worry about varargs changes at all. > > >> This will break unprototyped calls. > > >> 2) extend rax to pass info about if __m256 registers are present and > > >> upper half needs to be saved. > > >> This will break passing __m256 arguments to functions with prologues > > >> compiled with legacy compiler that will do wild jump. All other cases > > >> should work > > >> 3) Save upper halves whenever we want to save SSE registers. This will > > >> break calling variadic functions compiled with __m256 support in. > > >> > > >> I guess either 1) or 2) is fine for me, as I told earlier, I am not big > > >> fan of 3). I guess 1) is easier and probably make more sense? > > > > > > I vote for 1), though I think it should be passed on stack only for ... > > > args. E.g. for > > > void foo (__m256 x, ...); > > > void bar (__m256 x, __m256 y, __m256 z) > > > { > > > foo (x, y, z); > > > } > > > the first argument would be passed in %ymm0, while the unnamed arguments > > > y and z would be pushed to stack. > > > > > > > I agree. We will add testcases for whatever psABI extension we have > > chosen. > > I guess we all agree on passing variadic arguments on stack (that is > only those belonging on ...) and rest in registers. It seems easiest in > regard to future register set extensions too. Only negative thing is > that calls to variadic functions will become bit longer, but I guess it > is not big deal. (the fact that register passing conventions are shorter > and variadic functions tends to be called many times was also original > motivation to support register passing on pretty much everything for > varargs in psABI) > There is no precedent for passing named parameters in registers but unnamed parameters on the stack. On IA32 for the __m128 types, we pass ALL __m128 parameters on the stack for varargs functions, not just the unnamed ones. I think we should do the same for x86-64. H.J.