> On Tue, Jun 10, 2008 at 8:11 AM, Jakub Jelinek <[EMAIL PROTECTED]> 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)

Would you mind preparing psABI patch too?

Thanks,
Honza
> 
> Thanks.
> 
> -- 
> H.J.

Reply via email to