[cfe-dev] struct copy

Argiris Kirtzidis akyrtzi at gmail.com
Wed Oct 1 16:06:47 PDT 2008

Chris Lattner wrote:
> Why is there so much focus on this?  Is there a specific problem 
> you're trying to solve?  There are lots of real problems to tackle too :)

The LLVM type system is sophisticated enough to free the front-ends from 
the burden of dealing with holes and padding when copying a struct. They 
could just emit a load/store (even for large structs) and trust the 
backend to handle it efficiently.

Also, a load/store encodes more type information in the IR than a 
memmove. This can be useful when examining the LLVM IR; for a more 
specific example:
The MSIL backend can see the load/store and convert it to a direct 
MSIL-type load/store. This is simpler and more efficient that 
translating a memmove into MSIL code.

> Yep, that would be fine as long as the holes aren't used.  If you had  
> a struct {char, short} in C, it would be fine to use a load/store with  
> a first class aggregate.  The only case that is tricky is when you  
> have unions mixed in there.

Unions would be handled properly if there were no gaps in them, is this 
correct ?
(A type without holes in it seems like the right way to represent a union)


More information about the cfe-dev mailing list