> >
> > 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 you need 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
>
> 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
> >
