[cfe-dev] struct copy

[Chris Lattner]

On Oct 1, 2008, at 12:55 AM, Matthijs Kooijman 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 :)
> It's not the core problem for me, but I do think that the bitcode  
> resulting
> from unions is more clear and readable when using the clang way.
>
> But, the problem we were trying to solve was how to model the  
> copying of a
> struct, ie use a memmove or load/store, etc. When unions are  
> involved, the
> copying of gaps in a struct becomes essential for correct functioning.
> However, in the normal struct case, the gaps can be omitted when  
> copying
> (which is useful for things like scalarrepl), though it does not  
> hurt to
> include them as well (which might be beneficial for performance).

Note that scalarrepl should be able of promoting allocas that are  
memcpy'd from or to.

> So, in this light, perhaps you can comment on what I wrote earlier:
>
>>> What does load/store currently mean exactly for a struct with  
>>> gaps? The
>>> langref doesn't seem to mention this explictly, but I think that  
>>> currently a
>>> load and store of a struct type are not allowed to access the gaps?

A load of a first class aggregate with holes does not load the holes.   
It conceptually does an element-by-element load.  A store of a first  
class aggregate is undefined whether it overwrites any holes.

>>> One could consider saying that a load and store of a struct types  
>>> are allowed
>>> to access the gaps, but not required to. In this case, it makes  
>>> sense to keep
>>> the struct load/store around for as long as possible, so the code  
>>> generator
>>> can in the end decide how to lower them.

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.

>>> Are there usecases where a load or store of a struct with gaps  
>>> must really not
>>> access the gaps? I can imagine this is more likely for the padding  
>>> at the end
>>> though. In any case, perhaps this could/should be an extra flag to  
>>> load and
>>> store or something?

I can't think of any case, but even if there is I really don't want to  
add a flag that says "don't access the gaps" :)

-Chris