Anything could live there. Run this IR through clang and you'll see an
alloca with a struct type where the padding is used by memset and
'use_bytes':
#include <string.h>
void use_bytes(char *);
int main() {
union {
char bytes[8];
struct {
char c;
int i;
} with_padding;
} u = { .with_padding = {'a', 42} };
memset(u.bytes, 8, 0);
use_bytes(u.bytes);
}
On Thu, Apr 16, 2015 at 9:57 PM, Xin Tong <trent.tong at gmail.com> wrote:
> Hi
>
> I see that LLVM does not scalar replace aggregates used as the src or
> dst of memcpy. and the reason is memcpy could be moving around
> elements that live in structure padding of the LLVM types. I wonder
> what could live in the padding, but may actually used ?
>
> 02605 // Okay, we know all the users are promotable. If the
> aggregate is a memcpy
> 02606 // source and destination, we have to be careful. In
> particular, the memcpy
> 02607 // could be moving around elements that live in structure
> padding of the LLVM
> 02608 // types, but may actually be used. In these cases, we refuse
> to promote the
> 02609 // struct.
> 02610 if (Info.isMemCpySrc && Info.isMemCpyDst &&
> 02611 HasPadding(AI->getAllocatedType(), DL))
> 02612 return false;
>
> Thanks
> Trent
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150417/ad6d1f94/attachment.html>