[LLVMdev] PROPOSAL: IR representation of detailed struct assignment information (new version)

[Chandler Carruth]

On Mon, Sep 10, 2012 at 11:56 AM, Peter Cooper <peter_cooper at apple.com>wrote:

> Hi Chandler
>
> 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.
>

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.

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.

The goal is quite simply this:

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.

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.

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.


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120910/05e66c1c/attachment.html>