This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Extend x86-64 psABI for 256bit AVX register


> On Wed, Jun 11, 2008 at 07:49:12AM -0700, H.J. Lu wrote:
> > > 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.
> 
> Why should the 32-bit ABI influence x86-64 ABI decisions?
> There are clear advantages of passing __m128 named arguments in registers
> (shorter/faster code both on the caller and callee side) and there
> are advantages of passing __m128 unnamed arguments on the stack
> (for va_arg to work, they need to be on the stack, and if they
> are passed in registers, the callee would need to push them
> to the stack).

For record I would also preffer passing all named AVX arguments in
registers.  x86-64 ABI was designed for performance not for backward
compatibility, so it should be consistent with original idea and I think
that ABIs are divergent anough so this won't cause too much of extra
confussion.  But I am happy with both solutions.

Honza
> 
> 	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]