This is the mail archive of the 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 02:02:13:

> > > 
> > > I am on that tricky thing ;) I think I need in i386.c an global 
> > > "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 
> > > 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.
> 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 
>    (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 
>    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 !?!

 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

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