public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: marxin <mliska@suse.cz>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	hrishikeshparag@gmail.com, 	Jan Hubicka <hubicka@ucw.cz>
Subject: Re: [PATCH 2/3] Add lto-dump tool.
Date: Fri, 26 Apr 2019 13:14:00 -0000	[thread overview]
Message-ID: <CAFiYyc0w07QP=kApb2boAgNWohQsVyjmAVwf6Z=pQcvFC_Mzcw@mail.gmail.com> (raw)
In-Reply-To: <00d68e39b80bb63105d123a2481b218b3b1e66cc.1552571776.git.mliska@suse.cz>

On Thu, Mar 14, 2019 at 3:00 PM marxin <mliska@suse.cz> wrote:
>

I think it's a good start.  Some minor nits:

+/* Dump the visibility of the symbol.  */
+
+const char *
+symtab_node::dump_visibility () const
+{
+  static const char * const visibility_types[]
+    = { "default", "protected", "hidden", "internal" };
+  return visibility_types[DECL_VISIBILITY (decl)];
+}
+
+/* Dump the type_name of the symbol.  */
+const char *
+symtab_node::dump_type_name () const
+{
+  return symtab_type_names[type];
+}

Both method names are not very good.  I guess the first
should be get_visibilitiy_string and the second
get_symtab_type_string?  Because they do not actually
dump.

For the function statistics I wonder if we really need the
untransformed body or if we can resort to inline information
that must be also in the LTO stream.

Otherwise looks OK to me.

Thanks,
Richard.

> gcc/ChangeLog:
>
> 2019-03-14  Hrishikesh Kulkarni  <hrishikeshparag@gmail.com>
>             Martin Liska  <mliska@suse.cz>
>
>         * Makefile.in: Add lto-dump.texi.
>         * cgraph.h: Add new functions dump_visibility and
>         dump_type_name.
>         * doc/gcc.texi: Include lto-dump section.
>         * doc/lto-dump.texi: New file.
>         * dumpfile.c (dump_switch_p_1): Use parse_dump_option.
>         (parse_dump_option): Factor out this function.
>         * dumpfile.h (enum dump_flag): Add new value TDF_ERROR.
>         (parse_dump_option): Export the function.
>         * symtab.c (symtab_node::dump_visibility): New function.
>         (symtab_node::dump_type_name): Likewise.
>
> gcc/lto/ChangeLog:
>
> 2019-03-14  Hrishikesh Kulkarni  <hrishikeshparag@gmail.com>
>             Martin Liska  <mliska@suse.cz>
>
>         * Make-lang.in: Add lto_dump-related definition.
>         * config-lang.in: Likewise.
>         * lang.opt: Add new language LTODump and options related
>         to LTO dump tool.
>         * lto-common.c (lto_read_decls): Support type statistics dump.
>         (lto_file_read): Likewise for object files.
>         * lto-dump.c: New file.
>         * lto-lang.c (lto_option_lang_mask): Move from ..
>         * lto.c (lto_option_lang_mask): .. here.
>         * lto.h (lto_option_lang_mask): New declaration.
> ---
>  gcc/Makefile.in        |   2 +-
>  gcc/cgraph.h           |   6 +
>  gcc/doc/gcc.texi       |   5 +
>  gcc/doc/lto-dump.texi  | 131 ++++++++++++++++
>  gcc/dumpfile.c         |  85 ++++++----
>  gcc/dumpfile.h         |   5 +
>  gcc/lto/Make-lang.in   |  20 ++-
>  gcc/lto/config-lang.in |   4 +-
>  gcc/lto/lang.opt       |  62 ++++++++
>  gcc/lto/lto-common.c   |  40 +++++
>  gcc/lto/lto-dump.c     | 344 +++++++++++++++++++++++++++++++++++++++++
>  gcc/lto/lto-lang.c     |   6 -
>  gcc/lto/lto.c          |   6 +
>  gcc/lto/lto.h          |   2 +
>  gcc/symtab.c           |  17 ++
>  15 files changed, 692 insertions(+), 43 deletions(-)
>  create mode 100644 gcc/doc/lto-dump.texi
>  create mode 100644 gcc/lto/lto-dump.c
>

  reply	other threads:[~2019-04-26 12:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-14 14:00 [PATCH 0/3][stage1] [PATCH v2] LTO dump tool marxin
2019-03-14 14:00 ` [PATCH 3/3] Fix GNU coding style in lto-common.c marxin
2019-04-29 19:43   ` Jeff Law
2019-03-14 14:00 ` [PATCH 2/3] Add lto-dump tool marxin
2019-04-26 13:14   ` Richard Biener [this message]
2022-10-28 10:14   ` Thomas Schwinge
2022-10-29  3:22     ` Jeff Law
2019-03-14 14:06 ` [PATCH 1/3] Split part of functionality from lto.c to lto-common.c marxin
2019-04-26 12:47   ` Richard Biener

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='CAFiYyc0w07QP=kApb2boAgNWohQsVyjmAVwf6Z=pQcvFC_Mzcw@mail.gmail.com' \
    --to=richard.guenther@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hrishikeshparag@gmail.com \
    --cc=hubicka@ucw.cz \
    --cc=mliska@suse.cz \
    /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).