llvm dev - Aug 2012 - [LLVMdev] PROPOSAL: IR representation of detailed struct assignment information

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?

On the other hand, TBAA is only half the story here; the other half is
describing struct padding. I don't have strong opinions here; does anyone
else?

Dan

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.
> 
> 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.

Thanks again,
Hal
> I don't have strong opinions here; does
> anyone else?
> 
> Dan
> 


-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory

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