struct copy

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 :slight_smile:

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" :slight_smile:

-Chris

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 :slight_smile:

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)

-Argiris