[llvm-dev] RFC: Up front type information generation in clang and llvm
Eric Christopher via llvm-dev
llvm-dev at lists.llvm.org
Mon Apr 4 14:23:23 PDT 2016
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
> > Proposal
> > =======
> > Short version
> > -----------------
> > 1. Split the DIBuilder API into Types (+Macros, Imports, …) and Line
> > 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
> > 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?
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.
> Carlo Kok
> RemObjects Software
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev