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

Chris Lattner clattner at apple.com
Fri Sep 7 13:29:23 PDT 2012


On Sep 7, 2012, at 1:14 PM, Dan Gohman <gohman at apple.com> wrote:
>>> 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}

Yeah, that's what I was thinking.  This MDNode should be usable by any struct copy of that type.  Duncan, what do you think?  I'm skeptical of an approach that requires varargs overloaded intrinsics. :-)

-Chris



More information about the llvm-dev mailing list