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

[Hal Finkel]

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