This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH v3] Make function clone name numbering independent.
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Michael Ploujnikov <michael dot ploujnikov at oracle dot com>
- Cc: Martin Jambor <mjambor at suse dot cz>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jan Hubicka <hubicka at ucw dot cz>, Segher Boessenkool <segher at kernel dot crashing dot org>
- Date: Fri, 30 Nov 2018 08:25:59 +0100
- Subject: Re: [PATCH v3] Make function clone name numbering independent.
- References: <a8a7ea06-98f3-1b7c-d0bb-4e428cb97cf3@oracle.com> <6A1E6E88-63F7-43E4-8A53-78C7694D34BE@gmail.com> <CAFiYyc1Vcbx7NQBLAbTLrQmFmdOTCX_PrzuLf4CJ9KnKzJSHTQ@mail.gmail.com> <069cb2a6-2e37-58fb-2009-35e0300270f1@oracle.com> <618e046e-3f28-f008-237d-497bcff2531e@oracle.com> <CAFiYyc3fgCkaF0=XvzSDnLoM47a2OgAn0PA8x8Xm3zPJ-D1v-Q@mail.gmail.com> <121c01f4-c1a2-249e-2cac-c6d5ec250fcb@oracle.com> <702ab3f1-fe25-9013-7a1e-f5e1615c9396@oracle.com> <85bd8119-0bce-a06d-df3f-1a1a6ed88187@oracle.com> <CAFiYyc0bF72pX8rr4krbxi6RmKn8VyzKz7VyTEAAeQQJyKXoFQ@mail.gmail.com> <bfd6145a-d8f0-1fa9-5375-77e4e314bcd3@oracle.com> <3167e521-aa5b-e47c-6d9b-956a1af2a886@oracle.com> <078bf036-f02b-3bdb-545d-3f5ad67bc786@oracle.com> <ri636uqlx0q.fsf@suse.cz> <CAFiYyc1dadUexNFtsifE1yUa+oc2np2+Ga2h-XUzmkRkAuzBPg@mail.gmail.com> <ri6y3cik9hf.fsf@suse.cz> <3f9e8c2a-6112-b595-a932-137958e61f5e@oracle.com> <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