[cfe-dev] struct copy

[Matthijs Kooijman]

Hi Chris,

>> If an alloca of a union is in fact only used as its struct type and never
>> as any of the other types, then instcombine will change the i8 array alloca
>> to a struct alloca and scalarrepl will still be able to do its work just
>> fine.
> Hrm... this is a big maybe.  The instcombine xform has a lot of constraints 
> on it.
I don't think there are a lot of problems here, but you might be right that
instcombine doesn't solve this problem well enough yet. In particular, I
suspect that having multiple uses of an alloca (even when they are all the
same bitcast) and having a part of the union that is smaller than the entire
union, might throw instcombine off here. However, it might be worthwile to
improve this inscombine xform for this purpose, since clang uses this as well.

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

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

Gr.

Matthijs