[LLVMdev] PROPOSAL: IR representation of detailed struct assignment information (new version)

[Dan Gohman]

On Sep 7, 2012, at 10:28 AM, Chris Lattner <clattner at apple.com> wrote:
> 
> On Sep 6, 2012, at 4:24 PM, Dan Gohman <gohman at apple.com> wrote:
> 
>> Here's the example showing the basic problem:
>> 
>> struct bar {
>> char x;
>> float y;
>> double z;
>> };
>> void copy_bar(struct bar *a, struct bar *b) {
>> *a = *b;
>> }
>> 
>> The solution I now propose here is to have front-ends describe the copy
>> using metadata. For example:
>> 
>> call void @llvm.memcpy.p0i8.p0i8.i64(i8* %0, i8* %1, i64 16, i32 8, i1 false), !tbaa.struct !4
>> […]
>> !0 = metadata !{metadata !"Simple C/C++ TBAA"}
>> !1 = metadata !{metadata !"omnipotent char", metadata !0}
>> !2 = metadata !{metadata !"float", metadata !1}
>> !3 = metadata !{metadata !"double", metadata !1}
>> !4 = metadata !{metadata !5, i64 3, metadata !6, metadata !7}
>> !5 = metadata !{i64 1, metadata !1}
>> !6 = metadata !{i64 4, metadata !2}
>> !7 = metadata !{i64 8, metadata !3}
>> 
>> Metadata nodes !0 through !3 are regular TBAA nodes as are already in use.
>> 
>> Metadata node !4 here is a top-level description of the memcpy. It holds a
>> list of virtual members. An integer represents a padding field of that
>> size. A metadata tuple represents an actual data field. The tuple's members
>> are an integer size and a TBAA tag for the field.
> 
> How about just making "!4" be a list of triples, where the first two elements are integer offset/size, and the third entry is a TBAA pointer, or null for padding?  This would give us easier to read (and pretty print) llvm IR and may be more memory efficient as well.


So, like this?

!4 = metadata !{i64 0, i64 1, metadata !1, i64 1, 64 3, i8* null, i64 4, i64 4, metadata !2, i64 8, i64 8, metadata !3}

Dan