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

Chandler Carruth chandlerc at google.com
Mon Sep 10 15:20:29 PDT 2012


On Mon, Sep 10, 2012 at 3:17 PM, Dan Gohman <gohman at apple.com> wrote:

>
> On Sep 10, 2012, at 2:54 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>
> > On Mon, 10 Sep 2012 11:29:37 -0700
> > Chandler Carruth <chandlerc at google.com> wrote:
> >
> >>
> >> Essentially, LLVM is trying to simplify ABI layout by providing a
> >> datalayout summary description of target alignments, and building
> >> structs with that algorithm. But unless this *exactly* matches the
> >> ABI in question, it actually makes the job harder because now we have
> >> to try, potentially fail, and end up with all the code to use the
> >> packed mode anyways. My theory is that there are too many ABIs in the
> >> world (and too weird rules within them) for us to ever really get
> >> this right at the LLVM layer.
> >
> > This layout logic needs to live somewhere, why can't it live in LLVM?
> > Does LLVM not have all of the necessary information for some ABIs? If
> > we push all of the necessary information and the associated logic into
> > the LLVM layer, then it can be used by multiple frontends.
>
> The LLVM layer does not currently have all of the necessary information.
> Bitfields, unions, and inheritance, are some things that are not captured.
> You could extend LLVM's type system to represent all these things, and
> it might make some things nicer, but how much complexity would it require,
> to make LLVM in general aware of this more complex type system?


Indeed, I think that we should move the opposite direction. I think LLVM
should be exposing a more low-level concept of layout than what it does.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120910/8a9ddfdb/attachment.html>


More information about the llvm-dev mailing list