[llvm-commits] Struct-handling patches

[Matthijs Kooijman]

Hi Dan,

> > Yeah, I hadn't thought of that. However, doesn't this problem arise in case of
> > a memcpy of a {double}. I'm completely unsure of how this works, but if double
> > is the same as fp80, ie a 10 byte value, and the struct, and thus a memcpy of
> > it, gets a size of 16 bytes (due to alignment?), then replacing sucy a memcpy
> > with load + store will skip the 6-byte hole at the end of the struct, right?
> > It might very well be that any or all of the assumptions in the above are
> > wrong, though.
> the HasPadding method takes care of this.  For x86 long double it's taken
> care of by this line:
> 
>   return TD.getTypeSizeInBits(Ty) != TD.getABITypeSizeInBits(Ty);
> 
> The LHS is 80, the RHS is 96 or 128 depending on the platform.
But where exactly is HasPadding used? Or do you mean "should/could take care
of this" ?

In particular, I looked a bit closer at the SimplifyMemTransfer. The only
thing they do there regarding sizes of the types juggled, is comparing if the
store size of the struct type that's memcpy'd is equal to the memcpy size.
Since the store size includes padding, this is probably the case. However, for
the {double} case ( a double is 10 bytes, right?), this will probably mean
that a store of type double will not include this padding, while the original
memcpy didn't.

Ie, I have this feeling that there is a bug in SimplifyMemTransfer regarding
this, but I don't have the time to find a testcase right now.

Gr.

Matthijs