[llvm-commits] [llvm-gcc-4.2] r46164 - in /llvm-gcc-4.2/trunk/gcc/config/i386: llvm-i386-target.h llvm-i386.cpp

[Dale Johannesen]

On Jan 23, 2008, at 7:05 PM, Evan Cheng wrote:

>
> On Jan 22, 2008, at 11:23 PM, Duncan Sands wrote:
>>
>> Can you please clarify the roles of llvm-gcc and the code generators
>> in getting ABI compatibility.  When generating IR for x86-64, llvm- 
>> gcc
>> sometimes chops by-value structs into pieces, and sometimes passes  
>> the
>> struct as a byval parameter.  Since it chops up all-integer structs,
>> and this corresponds more or less to what the ABI says, I assumed  
>> this
>> was an attempt to get ABI correctness.  Especially as the code
>> generators
>> don't seem to bother themselves with following the details of the
>> ABI (yet),
>> and just push byval parameters onto the stack.  Since you say
>
> If ABI specifies the aggregate should be passed in memory, then llvm-
> gcc passes it byval. Otherwise, it chops up in pieces following the
> ABI specification (only x86-64 uses a mixture of integer and non-
> integer registers).

Just noticed this...Darwin ppc64 also uses a mix of registers.  The same
struct can use int, float, vector registers and memory in extreme cases.

>>>> This is an optimization, not a correctness issue
>>
>> I guess this means that the plan is to teach the codegenerators how  
>> to
>> pass any aggregate byval in an ABI conformant way (not the case
>> right now),
>> but still do some chopping up in the front-end to help the  
>> optimizers.
>> Of course this chopping up needs to be done carefully so the final
>> result
>> squirted out by the codegenerators (once they are ABI conformant)
>> is the
>> same as if the chopping had not been done...  Is this chopping
>> really a
>> big win?  Is it not possible to get an equivalent level of
>> optimization
>> by enhancing alias analysis?
>
> We are only doing thise for small integer aggregates that are not
> passed through registers. This guarantees ABI compliance. Chopping it
> up into small integer pieces ensure the code generator does not make
> a copy of the object (among other potential benefits). One day when
> the code generator is smarter about it then perhaps we can eliminate
> this optimization.
>
> Evan
>
>>
>> Ciao,
>>
>> Duncan.
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits