[llvm-dev] RFC: Up front type information generation in clang and llvm
Peter S. Housel via llvm-dev
llvm-dev at lists.llvm.org
Mon Apr 4 14:26:48 PDT 2016
On 04/04/2016 05:06 AM, Carlo Kok via llvm-dev 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.
>> 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.
>> 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.
The Open Dylan compiler doesn't link with any LLVM libraries; its only
interface with LLVM is through bitcode, using a bitcode writer that I
wrote myself in Dylan. Frontends that write textual LLVM assembly are in
the same situation.
The type information that the Open Dylan LLVM support generates within
debug information is very simple, mostly amounting to void* (and
function signatures containing varying numbers of void* arguments). It
sometimes goes beyond this when foreign (C) function support is used
within Dylan programs.
We would prefer if some level of support were maintained for generating
least-common-denominator debug info (both DWARF and CodeView) from
structured metadata. The potential performance improvements from
implementing this proposal don't really apply to our compiler's use
case, since the debug types for foreign C structs that are generated
generally only appear in a single translation unit across the entire
program. I'd prefer to avoid having to maintain code that deals with
DWARF and CodeView directly.
-Peter S. Housel-
More information about the llvm-dev