public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Michael Ploujnikov <michael.ploujnikov@oracle.com>
Cc: Martin Jambor <mjambor@suse.cz>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
		Jan Hubicka <hubicka@ucw.cz>,
	Segher Boessenkool <segher@kernel.crashing.org>
Subject: Re: [PATCH v3] Make function clone name numbering independent.
Date: Fri, 30 Nov 2018 07:26:00 -0000	[thread overview]
Message-ID: <CAFiYyc0RqvSYCzBpHYwufN4DKMSf9au_NFj2pGjqic7WCefe-A@mail.gmail.com> (raw)
In-Reply-To: <ded14873-6181-849f-6a3e-faf804d3f097@oracle.com>

On Wed, Nov 28, 2018 at 10:09 PM Michael Ploujnikov
<michael.ploujnikov@oracle.com> wrote:
>
> Continuing from https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00228.html
>
> It took longer than expected, but I've finally rebased this on top of
> the new clone_function_name* API and included the requested
> optimizations.
>
> There are a few remaining spots where we could probably apply similar
> optimizations:
>
> - gcc/multiple_target.c:create_target_clone
> - gcc/multiple_target.c:create_dispatcher_calls
> - gcc/omp-expand.c:grid_expand_target_grid_body
>
> But I've yet to figure out how these work in detail and with the new
> API these shouldn't block the main change from being merged.
>
> I've also included a small change to rs6000 which I'm pretty sure is
> safe, but I have no way of testing.
>
> I'm not sure what's the consensus on what's more appropriate, but I
> thought that it would be a good idea to keep these changes as separate
> patches since only the first one really changes behaviour, while the
> rest are optimizations. It's conceivable that someone who is
> backporting this to an older release might want to just backport the
> core bits of the change. I can re-submit it as one patch if that's
> more appropriate.
>
> Everything in these patches was bootstrapped and regression tested on
> x86_64.
>
> Ok for trunk?

+  unsigned &clone_number = lto_clone_numbers->get_or_insert (
+     IDENTIFIER_POINTER (DECL_NAME (decl)));
   name = maybe_rewrite_identifier (name);
   symtab->change_decl_assembler_name (decl,
-      clone_function_name_numbered (
-  name, "lto_priv"));
+      clone_function_name (
+  name, "lto_priv", clone_number));

since we use 'name' from maybe_rewrite_identifier in the end wouldn't it
make more sense to use that as a key for lto_clone_numbers?

For the ipa-hsa.c changes since we iterate over all defined functions
we at most create a single clone per cgraph_node.  That means your
hash-map keyed on cgraph_node is useless and you could use
an unnumbered clone (or a static zero number).

-  SET_DECL_ASSEMBLER_NAME (new_decl, clone_function_name_numbered (old_decl,
-   suffix));
+  SET_DECL_ASSEMBLER_NAME (new_decl,
+   clone_function_name (
+     IDENTIFIER_POINTER (
+       DECL_ASSEMBLER_NAME (old_decl)),
+     suffix,
+     num_suffix));

can you please hide the implementation detail of accessing the assembler name
by adding an overload to clone_function_name_numbered with an explicit
number?

OK with those changes.

Thanks,
Richard.



>
> - Michael

  parent reply	other threads:[~2018-11-30  7:26 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-16 19:38 [PATCH] " Michael Ploujnikov
2018-07-17  6:10 ` Bernhard Reutner-Fischer
2018-07-17 10:03   ` Richard Biener
2018-07-17 20:25     ` Michael Ploujnikov
2018-07-20  2:49       ` Michael Ploujnikov
2018-07-20 10:05         ` Richard Biener
2018-07-24 13:57           ` Michael Ploujnikov
2018-07-26 17:27             ` Michael Ploujnikov
2018-07-31 17:40               ` Michael Ploujnikov
2018-08-01 10:38                 ` Richard Biener
2018-08-02 19:05                   ` Michael Ploujnikov
2018-08-13 23:58                     ` [PING][PATCH] " Michael Ploujnikov
2018-08-20 19:47                       ` Jeff Law
2018-08-31 18:49                       ` [PING v2][PATCH] " Michael Ploujnikov
2018-09-03 10:02                         ` Martin Jambor
2018-09-03 11:08                           ` Richard Biener
2018-09-03 13:15                             ` Martin Jambor
2018-09-05  3:24                               ` Michael Ploujnikov
2018-11-28 21:09                                 ` [PATCH v3] " Michael Ploujnikov
2018-11-28 22:49                                   ` Segher Boessenkool
2018-11-29 14:13                                     ` Michael Ploujnikov
2018-11-30  7:26                                   ` Richard Biener [this message]
2018-11-30 21:11                                     ` Michael Ploujnikov
2018-12-01 16:31                                       ` H.J. Lu
2018-12-03 17:00                                         ` Michael Ploujnikov
2018-12-04  3:06                                           ` Michael Ploujnikov
2018-12-04 14:07                                             ` Jan Hubicka
2018-09-05  3:32                           ` [PING v2][PATCH] " Michael Ploujnikov
2018-12-04 12:48                             ` Martin Jambor
2018-12-04 13:22                               ` Michael Ploujnikov

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=CAFiYyc0RqvSYCzBpHYwufN4DKMSf9au_NFj2pGjqic7WCefe-A@mail.gmail.com \
    --to=richard.guenther@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=michael.ploujnikov@oracle.com \
    --cc=mjambor@suse.cz \
    --cc=segher@kernel.crashing.org \
    /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).