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

[Peter Cooper]

On Aug 31, 2012, at 3:13 PM, Chris Lattner <clattner at apple.com> wrote:

> On Aug 30, 2012, at 1:34 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote:
>> On 8/22/2012 3:15 PM, Dan Gohman wrote:
>>> Here's an example showing the basic problem:
>>> 
>>> struct bar {
>>>  char x;
>>>  float y;
>>>  double z;
>>> };
>>> void copy_bar(struct bar *a, struct bar *b) {
>>>  *a = *b;
>>> }
>>> 
>>> We get this IR:
>>> 
>>>  call void @llvm.memcpy.p0i8.p0i8.i64(i8* %0, i8* %1, i64 16, i32 8, i1 false)
>>> 
>>> This works, but it doesn't retain the information that the bytes between fields
>>> x and y don't really need to be copied, and it doesn't inform the optimizer
>>> that there are three fields with TBAA-relevant types being copied.
>>> 
>>> The solution I propose here is to have front-ends describe the copy using
>>> metadata. For example:
>> 
>> Why not simply have something like this?
>> 
>> %1 = load bar* %b
>> store %1, bar* %a
> 
> That preserves an IR type, but not source level types.  IR types are insufficient for TBAA or "hole" information.
But do IR types have to remain insufficient?  Couldn't we ensure the front-end adds fields to the IR types for all bytes which really exist (in any one of the unioned types).  Then holes in the IR type really are holes and we wouldn't need new metadata for holes.

In your example from earlier:

union x {
 struct { char b;  int c; } a;
 short b;
} u;

currently generates

%union.x = type { %struct.anon }
%struct.anon = type { i8, i32 }

but would fully describe all the holes if it was

%union.x = type { %struct.anon }
%struct.anon = type { i8, i8, i32 }

Pete
> 
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev