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

Dan Gohman gohman at apple.com
Mon Sep 10 17:21:36 PDT 2012

On Sep 10, 2012, at 3:19 PM, Chandler Carruth <chandlerc at google.com> wrote:

> On Mon, Sep 10, 2012 at 2:11 PM, Dan Gohman <gohman at apple.com> wrote:
> On Sep 10, 2012, at 11:29 AM, Chandler Carruth <chandlerc at google.com> wrote:
> >
> > Hey Dan, I've talked with you about this in person and on IRC, but I've not yet laid out my thoughts on a single place, so I'll put them here.
> >
> > TL;DR: I really like the idea of using metadata to tag each member of a struct with TBAA, and re-using the TBAA metadata nodes we already have. I'm not as fond of the description of padding in the metadata node.
> >
> > Currently padding is really hard to represent because there is sometimes a member of an LLVM struct which represents padding (packed structs and cases where the frontend type requires more alignment than the datalayout string specifies) and other times there isn't. The current proposal doesn't entirely fix this because we still will need some way to annotate the members of structs inserted purely for the purpose of padding.
> This is not a problem in the current proposal, because it represents padding
> completely independently from the LLVM struct type.
> It is a complexity of your proposal that I find unfortunate. =/ I suspect it will also add a small amount of complexity to the consumers of the analysis based on my work on SROA, although its possible that pass is just unique in the questions it needs to ask.

As we discussed on IRC, it seems that the best thing to do here would be to
start by rewriting clang's struct layout code to use LLVM's packed struct
types instead of falling back to i8 arrays or other fall-back types. If that
works well, it sounds like it would be an improvement regardless, and it
would be a much better vantage point from which to consider actual changes
to the LLVM IR type system.

For now, I will proceed with my most recent metadata proposal. It's just
metadata, so if something better comes along, we can drop it.


More information about the llvm-dev mailing list