Type representation in CTF and DWARF

Nick Alcock nick.alcock@oracle.com
Fri Oct 18 16:04:00 GMT 2019


On 18 Oct 2019, Pedro Alves stated:

> On 10/18/19 2:21 PM, Richard Biener wrote:
>
>>>> In most cases local types etc are a fairly small contributor to the
>>>> total volume -- but macros can contribute a lot in some codebases.
>>> (The
>>>> Linux kernel's READ_ONCE macro is one I've personally been bitten by
>>> in
>>>> the past, with a new local struct in every use. GCC doesn't
>>> deduplicate
>>>> any of those so the resulting bloat from tens of thousands of
>>> instances
>>>> of this identical structure is quite incredible...)
>>>>
>>>
>>> Sounds like something that would be beneficial to do with DWARF too.
>> 
>> Otoh those are distinct types according to the C standard and since dwarf is a source level representation we should preserve this (source locations also differ). 
>
> Right.  Maybe some partial deduplication would be possible, preserving
> type distinction.  But since CTF doesn't include these, this is moot
> for now.

Yeah, the libctf API and existing CTF users only care if they're
assignment-compatible, which they are. We could preserve more
type-identity information if there was a need to do so, but none has yet
emerged.

-- 
NULL && (void)



More information about the Gcc-patches mailing list