[llvm-dev] RFC: Up front type information generation in clang and llvm

[Eric Christopher via llvm-dev]

On Mon, Apr 4, 2016 at 5:06 AM Carlo Kok via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> Op 2016-03-30 om 03:00 schreef Eric Christopher via llvm-dev:
> > Hi All,
> >
> > This is something that's been talked about for some time and it's
> > probably time to propose it.
> >
> > The "We" in this document is everyone on the cc line plus me.
> >
> > Please go ahead and take a look.
> >
> > Thanks!
> >
> > -eric
> >
> >
> > Motivation
> > ========
> >
> > Currently, types in LLVM debug info are described by the DIType class
> > hierarchy. This hierarchy evolved organically from a more flexible
> > sea-of-nodes representation into what it is today - a large, only
> > somewhat format neutral representation of debug types. Making this more
> > format neutral will only increase the memory use - and for no reason as
> > type information is static (or nearly so). Debug formats already have a
> > memory efficient serialization, their own binary format so we should
> > support a front end emitting type information with sufficient
> > representation to allow the backend to emit debug information based on
> > the more normal IR features: functions, scopes, variables, etc.
> >
> > Scope/Impact
> > ===========
> >
> > This is going to involve large scale changes across both LLVM and clang.
> > This will also affect any out-of-tree front ends, however, we expect the
> > impact to be on the order of a large API change rather than needing
> > massive infrastructure changes.
> >
>
> How will you make it on the order of a large api change? At the moment
> we build bitcode ourselves and generate dibuilder equivalent structures.
> wouldn't frontends need to do their own well, DWARF and CodeView
> writing? Especially the ones that are tied to the C only apis.
>
>
There will be some backend support. The hope is that it'll be a fairly
direct translation from the existing APIs.

I make no claims about C API as we don't handle types at the C API level
currently.


>
> > Proposal
> > =======
> >
> > Short version
> > -----------------
> >
> > 1. Split the DIBuilder API into Types (+Macros, Imports, …) and Line
> Table.
> > 2. Split the clang CGDebugInfo API into Types and Line Table to match.
> > 3. Add a LLVM DWARF emission library similar to the existing CodeView
> one.
> > 4. Migrate the Types API into a clang internal API taking clang AST
> > structures and use the LLVM binary emission libraries to produce type
> > information.
> > 5. Remove the old binary emission out of LLVM.
> >
>
> What about allow multiple debug info formats at once? The current format
> could potentially
> allow such an option in the future (i know it doesn't actually do it
> now), will the new option
> hardcode it to a single format?
>
>
What option?

I don't think this is much of a worry - at the very least it's probably not
much more difficult than doing it right now.

-eric



> --
> Carlo Kok
> RemObjects Software
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160404/ad38cc07/attachment.html>