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