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

[Evan Cheng]

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

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