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

[Chris Lattner]

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