Hi David,
I looked at those code. I have some concerns on this implementations.
1. in wgen_decl.cxx/wgen_expr.cxx, the code only remove Mreturn.bar9_temp_0
if
Need_Hidden_Parameter return true, which need first fake argument.
Should we also remove temp_0 for the case that the return value doesn't
require the first fake argument because temp copy is also not neccesary?
Normalize to
MCALL bar9
MSTID return_decl_1885
for all the cases? And leave for backend to handle the conversion for
better compatibility because the frontend should not use too much
about lower level information such as ABI.
2. I am also wondering in wn_lower.cxx, after lower_return_mstid is called
and
add_fake_parm is called. And later when the backend runs to lower_call,
.vcall will not be generated?
Because I cannot integrate those changes into the backend and actually run
the
code, my questions may be ambigurous.
Yin
----- Original Message -----
From: "David Coakley" <dcoak...@gmail.com>
To: "Sun Chan" <sun.c...@gmail.com>
Cc: "open64-devel" <open64-devel@lists.sourceforge.net>
Sent: Monday, May 16, 2011 10:40 PM
Subject: Re: [Open64-devel] patch for better AMD64 ABI compatibility
> It is generic. The document that describes the ABI (from
> http://www.x86-64.org) uses the term AMD64 instead of x8664, but the
> same ABI is used for Intel too.
>
> On Mon, May 16, 2011 at 6:22 PM, Sun Chan <sun.c...@gmail.com> wrote:
>> is this AMD64 ABI or generic X8664 ABI? I guess I don't know much
>> about Intel vs AMD ABI differences, if there is.
>> Sun
>>
>> On Tue, May 17, 2011 at 8:01 AM, David Coakley <dcoak...@gmail.com>
>> wrote:
>>> (Attachment added this time.)
>>>
>>> On Mon, May 16, 2011 at 5:01 PM, David Coakley <dcoak...@gmail.com>
>>> wrote:
>>>> Could a gatekeeper review the attached patch? It fixes some AMD64 ABI
>>>> compatibility problems and also eliminates some unnecessary struct
>>>> copies. The second part should apply to all targets.
>>>>
>>>> Here is the proposed log message:
>>>>
>>>>
>>>> Improve AMD64 ABI compliance and avoid unnecessary struct copies.
>>>>
>>>> For the following code, the compiler generated unnecessary struct
>>>> copies
>>>> for a return value that has a size too big to be passed in registers.
>>>>
>>>> typedef struct { char big[1024]; } C;
>>>> C gc;
>>>> extern C bar9 (void);
>>>> extern C check9 (void) { return bar9 (); }
>>>>
>>>> In this case there were two copies and one temporary variable
>>>> generated.
>>>> After this change the compiler does not generate any extra copies.
>>>>
>>>> According to the AMD64 ABI, the caller provides space for the return
>>>> value in a hidden first argument and this address is returned in %rax.
>>>> Previously the compiler was not following this rule.
>>>>
>>>> The change handles the similar cases of initialization by function
>>>> call ("C c = bar9();") and assignment to a pointer ("*cp = bar9()").
>>>>
>>>> Also, a complex long double field is now returned in the register pair
>>>> (%st0, %st1) as specified by the AMD64 ABI.
>>>>
>>>>
>>>>
>>>> I am still looking for a review for the patch I posted last week (May
>>>> 10) as well. Thanks,
>>>>
>>>> -David Coakley / AMD Open Source Compiler Engineering
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Achieve unprecedented app performance and reliability
>>> What every C/C++ and Fortran developer should know.
>>> Learn how Intel has extended the reach of its next-generation tools
>>> to help boost performance applications - inlcuding clusters.
>>> http://p.sf.net/sfu/intel-dev2devmay
>>> _______________________________________________
>>> Open64-devel mailing list
>>> Open64-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/open64-devel
>>>
>>>
>>
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Open64-devel mailing list
> Open64-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/open64-devel
>
>
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
