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