From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21919 invoked by alias); 10 Jun 2008 11:24:59 -0000 Received: (qmail 21911 invoked by uid 22791); 10 Jun 2008 11:24:58 -0000 X-Spam-Check-By: sourceware.org Received: from sunsite.ms.mff.cuni.cz (HELO sunsite.mff.cuni.cz) (195.113.15.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 10 Jun 2008 11:24:41 +0000 Received: from sunsite.mff.cuni.cz (localhost.localdomain [127.0.0.1]) by sunsite.mff.cuni.cz (8.13.8/8.13.8) with ESMTP id m5ABdMeb012549; Tue, 10 Jun 2008 13:39:22 +0200 Received: (from jakub@localhost) by sunsite.mff.cuni.cz (8.13.8/8.13.8/Submit) id m5ABdLdv012548; Tue, 10 Jun 2008 13:39:21 +0200 Date: Tue, 10 Jun 2008 11:24:00 -0000 From: Jakub Jelinek To: Jan Hubicka Cc: "H.J. Lu" , 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: <20080610113921.GX3726@sunsite.mff.cuni.cz> Reply-To: Jakub Jelinek References: <6dc9ffc80806050731s77b49d63id048d142d76560c9@mail.gmail.com> <20080605151511.GB24241@atrey.karlin.mff.cuni.cz> <6dc9ffc80806050914t76383385o380c0bb8ebc4e972@mail.gmail.com> <20080606082834.GC31743@kam.mff.cuni.cz> <20080606135026.GA14877@lucon.org> <20080606142813.GA18621@lucon.org> <20080609144054.GA13869@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080609144054.GA13869@atrey.karlin.mff.cuni.cz> User-Agent: Mutt/1.4.2.2i 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/msg00219.txt.bz2 On Mon, Jun 09, 2008 at 04:40:54PM +0200, Jan Hubicka wrote: > Still it seems to me that we can use extend current eax convention. > Currently the value must be in range 0...8 as it specify number of SSE > registers. We can pack both numbers into it. This way we get > unforutnately wild jump on case of AVX code calling non-AVX function and > passing in AVX arguments, but this seems less important than 1) and 2) > to me and I don't see how to get all three cases working. > > Duplicating the value seems OK with me if it simplifies implementation > significandly. I don't understand why you want to pass __m256 and 256-bit vector values to anonymous arguments in registers. The only thing the vararg functions would do with it would be save it somewhere on the stack. Given the x86_64 ABI, you can't expect calling an implicitly prototyped or non-vararg prototyped function which is actually defined as vararg function (as %rax wouldn't be properly initialized), which means you need a prototype for all vararg functions and at that point the caller can just do the job for the callee and push stuff on the stack. Then vararg prologue doesn't need to save %ymm* registers at all and va_arg will handle __m256 just fine. Jakub