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@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits