From: Pedro Alves <palves@redhat.com>
To: Richard Biener <richard.guenther@gmail.com>,
Nick Alcock <nick.alcock@oracle.com>
Cc: Indu Bhagat <indu.bhagat@oracle.com>,
Jakub Jelinek <jakub@redhat.com>,
gcc-patches <gcc-patches@gcc.gnu.org>,
mark@klomp.org
Subject: Re: Type representation in CTF and DWARF
Date: Fri, 18 Oct 2019 15:31:00 -0000 [thread overview]
Message-ID: <d969fde4-2211-cee8-7c86-0dfbbc62a0e2@redhat.com> (raw)
In-Reply-To: <4F6646B0-4998-4F04-8C8C-E45E3D8FAB18@gmail.com>
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.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2019-10-18 15:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-04 19:12 Indu Bhagat
2019-10-07 7:35 ` Richard Biener
2019-10-07 20:47 ` Indu Bhagat
2019-10-07 20:56 ` Jason Merrill
2019-10-08 15:37 ` Pedro Alves
2019-10-09 6:04 ` Indu Bhagat
2019-10-09 7:43 ` Richard Biener
2019-10-09 8:01 ` Jakub Jelinek
2019-10-10 23:07 ` Indu Bhagat
2019-10-11 11:27 ` Richard Biener
2019-10-11 11:47 ` Jakub Jelinek
2019-10-25 3:43 ` Indu Bhagat
2019-10-25 7:49 ` Richard Biener
2019-10-11 18:55 ` Indu Bhagat
2019-10-17 17:59 ` Nick Alcock
2019-10-17 18:09 ` Richard Biener
2019-10-17 19:12 ` Nick Alcock
2019-10-18 12:28 ` Pedro Alves
2019-10-18 13:27 ` Richard Biener
2019-10-18 15:31 ` Pedro Alves [this message]
2019-10-18 16:04 ` Nick Alcock
2019-10-18 11:59 ` Pedro Alves
2019-10-09 9:15 ` Segher Boessenkool
2019-10-15 15:30 ` Nick Alcock
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d969fde4-2211-cee8-7c86-0dfbbc62a0e2@redhat.com \
--to=palves@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=indu.bhagat@oracle.com \
--cc=jakub@redhat.com \
--cc=mark@klomp.org \
--cc=nick.alcock@oracle.com \
--cc=richard.guenther@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).