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
next prev 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).