[cfe-dev] struct copy

[Matthijs Kooijman]

Hi Chris,

> > Ah ok, "unions as the biggest field" is bad. How about if we  
> > consider unions as arrays (as clang does):
> >
> >   %struct.a = type { i8, double }
> >   %struct.c = type [12 x i8]
> That would solve this problem, but also isn't a universally good thing  
> to do.  Doing things like this can break the (critical for some codes)  
> Scalar Replacement of Aggregates optimization.
Can you give an actual example of this? By my reasoning, if a struct is really
part of a union, and the value is thus used in some other way, scalarrepl
wouldn't be able to split it up anyway, right?

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.

> In general, it is good  for the front-end to preserve as much accurate type
> info in the LLVM  IR as possible.
I agree with you here. However, I'm not so sure that picking one type a union
can become over another, is much more accurate than just picking an i8 array
always.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20080929/693cb741/attachment.sig>