[LLVMdev] PROPOSAL: IR representation of detailed struct assignment information

[Chris Lattner]

On Aug 27, 2012, at 12:58 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> On Mon, 27 Aug 2012 11:41:47 -0700
> Dan Gohman <gohman at apple.com> wrote:
>> On Aug 24, 2012, at 10:50 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>> 
>>> On Wed, 22 Aug 2012 13:15:30 -0700
>>> Dan Gohman <gohman at apple.com> wrote:
>>> 
>>>> call void @llvm.memcpy.p0i8.p0i8.i64(i8* %0, i8* %1, i64 16, i32
>>>> 8, i1 false), !struct.assignment !4 […]
>>> 
>>> I think that it would make more sense to name this !struct.tbaa --
>>> it seems logically similar to existing TBAA metadata (in that it is
>>> attached to the relevant load/store instruction).
>> 
>> How about !tbaa.struct, kicking off a prefix-namespace idiom?
> 
> Fine by me.

Another alternative would be to separate them into two different MDNodes: one for TBAA info, one for padding info.

>> On the other hand, TBAA is only half the story here; the other half is
>> describing struct padding.
> 
> By this you mean that it is possible to determine which parts of the
> copy are padding because we now have direct access to the pointer type
> information, right? Out of curiosity, is there a reason not to change
> the memcpy to take non-integer pointers? If memcpy took the
> struct pointer without needing the bitcast, then we'd have this
> information directly.

This is an interesting idea, particularly given that you're representing struct information with a null pointer.  I think that the limiting issue here is that intrinsics cannot encode/mangle general structs in their type signature.  What do you think Dan?

-Chris