AMD64 ABI compatibility

Jan Hubicka
Wed Jul 11 00:02:00 GMT 2007

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

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

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

More information about the Gcc mailing list