[cfe-dev] struct copy
Chris Lattner
clattner at apple.com
Wed Oct 1 10:53:47 PDT 2008
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
More information about the cfe-dev
mailing list