<div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 10, 2012 at 11:56 AM, Peter Cooper <span dir="ltr"><<a href="mailto:peter_cooper@apple.com" target="_blank" class="cremed">peter_cooper@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Chandler<div><br></div><div>I also brainstormed a little with Dan on this and one idea we had was to add a new LLVM type for the hole/padding.  This would be a type for which it is legal to load/store/move around as part of a larger move operation, but is otherwise unusable in LLVM.  Dan named it x32 for a 32-bit type for example.</div>
</div></blockquote><div><br></div><div>While I see some appeal to this, I'm specifically *not* proposing such a change. I think it introduces a lot more complexity than it is worth.</div><div><br></div><div>We already have a perfectly suitable type to represent members of a struct which exist for the purpose of padding things out: [N x i8] for some constant N. I would suggest continuing to use this type.</div>
<div><br></div><div>The goal is quite simply this:</div><div><br></div><div>LLVM's struct types should serve the one purpose they have when dealing with memory: encoding the useful offsets of members within the struct such that we can write compact IR for accessing members, and automatically selecting the appropriate primitive type of the member to ease the formation of a load or store.</div>
<div><br></div><div>This means the LLVM struct is already encoding the offset information and ranges between offsets. We should re-use that encoding for padding as well by having an member of the struct which represents *just* the range of the padding.</div>
<div><br></div><div>Then we can use metadata to encode the semantics which should be attached to these ranges of bytes. TBAA can provide aliasing buckets for the members, and this metadata could also mark that some [N x i8] members are ranges of padding bytes with no need for a new type in the IR.</div>
<div><br></div><div><br></div><div>What I really don't want is to have two separate encodings of the layout of a struct -- one in metadata and one in the LLVM type. I would like to additionally ensure that more types have reasonable encodings of their layout in the LLVM types, and I think that can be achieved by moving to packed-structs-only as a model.</div>
</div></div>