Jan Hubicka wrote on 11.07.2007 02:02:13:
> > >
> > > I am on that tricky thing ;) I think I need in i386.c an global
variable
> > > "ix86_amd64_abi" which helds the the current function abi. This
> means also
> > > that I have to use instead of TARGET_64BIT_MS_ABI this variable.This
var
> > > may initioalized by init_cumulative_args and the overriden
> > > REG_PARM_STACK_SPACE, OUTGOING_REG_PARM_STACK_SPACE, REGPARM_MAX,
> > > SSE_REGPARM_MAX, STACK_BOUNDARY, etc.
> >
> > In order to get all cases right (ie switching ABIs and calling foreign
> > function), you need more bookkeeping than this. I am just in hurry to
> > catch bus, but I will send you little guide tonight.
>
> Hi,
> so short overview. It seems to me that you have several cases:
>
> - to keep track of current function ABI, you need to add struct
> machine_function field (i386.g) and update TARGET_64BIT_MS_ABI that
> cares about current function ABI accordingly.
>
> To deal correclty with call_used registers, I think you need to set
> the bits at same time machine_function is initialized and add a
> function to regalloc that will update the internal representaiton via
> regset (grep for use of the macro).
>
> For example prologue/epologue code cares about this current ABI.
>
> - to keep track of ABI used by currently expanded function call
> CUMULATIVE_ARGS allows you to add extra info. See how cum->nregs
> is handled, you need to do pretty much the same and add cum argument
> to functions called form cumulative arguments machinery where youneed
them.
> (as opposed to flipping the current abi above as you suggested).
>
> There is one problem that RTL CALL instructions does not specify call
> used registers that differ in between ABI. They are all assumed to
> use ones specified by call_used.
>
> I think you can't do anything to declare SI/DI unused when calling
> function from SYSV ABI with MS ABI convention. We just lose code
> quality a bit.
>
> On the other hand you must specify them as clobbered when calling
> SYSV ABI from MS ABI. This needs to be done by adding extra variants
> of call instruction pattern with the clobber. You might want to
> impleement SYSV->MS direction only first and not worry about this for
> start.
>
> Note that when calling libcalls, you always want to use the efault
> conventions so the libgcc match.
>
> - You need to keep track of cases function from one ABI calls functions
> from different ABI. This can be done by adding yet another bit into
> machine_function and simply set it when expanding the foreign call.
>
> Some predicates (such as ix86_function_value_regno_p) cares about
> if the reg can possibly be return value. In the case both ABIs
> coexist in single function, you need to be conservative here and
> merge both possibilities.
>
> - You will need to update the calling convention of some of the
> predicates you mentioned (such as I think
OUTGOING_REG_PARM_STACK_SPACE)
> to specify the function declaration they care about (so you know if
> it is foreign call or not). GCC middleend is probably not quite
> ready to deal with so different ABIs intermixed at once. This
> include updating of calling conventions in all ports and should be
> done first by separate patches. Not dificult, but tedious.
>
> I guess thats it. I believe that if you don't do something of the
> above, some of cases will go wildly wrong... (this is not to discougrate
> you, just to explain why it is tricky :)
>
> Honza
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 !?!
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
