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: AMD64 ABI compatibility


> Jan Hubicka wrote on 11.07.2007 14:01:54:
> 
> > > 
> > > I thank you very much for your great help. Currently I am stucked on 
> > > x86_function_value_regno_p (macro FUNCTION_VALUE_REGNO_P). It is not 
> clear 
> > > what's to do here for the FIRST_FLOAT_REG case. Maybe I could use the 
> > > ms_abi variant for sysv_abi as default too. But I think, it breaks 87 
> fpu 
> > > stuff for this ABI !?!
> > 
> > x86_function_value_regno_p is tricky one.  Speaking strictly from
> > definition I think it should
> >  - for current SYSV ABI with no MS ABI function calls return set it
> >    returns for MS ABI (not including x87)
> >  - for current SYSV ABI or MS ABI with SYSV ABI function calls return 
> set it
> >    returns for SYSV ABI (including x87)
> > 
> > However see the use in builtins.c - it expects that this function is
> > invariant for whole compilation unit, so implementing the above would
> > need updating builtins.c too.
> > 
> > The feature is used just seldomly - for the extra builtin expansion,
> > in combine.c for logic that won't fire for x87, in mode switching to
> > support the builtin_apply above and in rtlanal.c to avoid separating
> > the return value from call. With x87 register we should not be spoiled
> > here either, since x87 is quite symetric before regstack and restackwill 
> know
> > how to fix this up.
> > 
> > My best bet would be that making the function dependent on default ABI
> > is good enough.  You might add some comment that the function should
> > depend on current function ABI but builtins.c would need updating then.
> > 
> > Honza
> 
> I noticed, that OUTGOING_REG_PARM_STACK_SPACE makes troubles too. What is 
> about extending this macro by a FNDECL argument ? This would solve the 
> problem and AFAICS the function declaration seems to be always present.

Yes, this is what I would suggest.  There is little trickery here -
OUTGOING_REG_PARM_STACK_SPACE is used in calls.c where it is function
call specific and I think adding decl argument will just do the right
thing.

Other use is in definition of STACK_DYNAMIC_OFFSET use in function.c
This case however cares if REG_PARM_STACK_SPACE	is present in currently
compiled function (that is if the current function has some call in MS
ABI mode).
I guess this can be dealt with adding
CURRENT_FUNCTOIN_OUTGOING_REG_PARM_STACK_SPACE that would DRT, but we need
to double check that defining it won't move all function arguments away
from top of stack breaking any calls to SYSV ABI mode in the same
function.

I am about to leave again, I will try to look into the implementation
later today (I am just about to leave now)

Honza
> 
> Cheers,
>  i.A. Kai Tietz
> 
> |  (\_/)  This is Bunny. Copy and paste Bunny
> | (='.'=) into your signature to help him gain
> | (")_(") world domination.
> 
> ------------------------------------------------------------------------------------------
>   OneVision Software Entwicklungs GmbH & Co. KG
>   Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
>   Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
>   Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
>   Handelsregister: HRA 6744, Amtsgericht Regensburg
>   Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
>   Dr.-Leo-Ritter-Straße 9 ??? 93049 Regensburg
>   Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: 
> Ulrike Döhler, Manuela Kluger
> 


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