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

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.

-Chris

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

On 31 August 2012 23:22, Peter Cooper <peter_cooper at apple.com>
wrote:
> Then holes in the IR type really are holes and we wouldn't need new
metadata for holes.
AFAIK, there's no way to forbid access to an IR type, or a sub-type.
In that case, the holes would be addressable, which is not
semantically valid in any language.

-- 
cheers,
--renato

http://systemcall.org/

On Aug 31, 2012, at 3:22 PM, Peter Cooper <peter_cooper at apple.com>
wrote:
>>>> 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.
It is possible to use IR types for hole information, but this doesn't solve
the TBAA need.    However, even if we wanted to use an IR type for hole
information, it would add more complexity all around (compared to representing
holes with a list of "hole ranges").

I described some of this here:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-August/052900.html

It also wouldn't be possible to specify something like "an i16 type
where the first byte is defined and the second byte is defined but has alignment
of 8 bits", and certainly wouldn't be able to do "the first byte
of an i16 memory object is undefined and the second byte is defined".  Hole
ranges handle these sorts of cases just fine.

-Chris