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

[Peter S. Housel via llvm-dev]

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

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-