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

[Carlo Kok via llvm-dev]

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.


> 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?

-- 
Carlo Kok
RemObjects Software