public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: Ilya Enkovich <enkovich.gnu@gmail.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [CHKP, PATCH] Fix LTO cgraph merge for instrumented functions
Date: Thu, 02 Apr 2015 17:01:00 -0000	[thread overview]
Message-ID: <20150402170115.GB21276@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <CAMbmDYZG20UY0pw8X0EmOvUDv7D+qFp6kfGR6zz-xQPAHvp4Uw@mail.gmail.com>

> Ping
It would help if you add hubicka@ucw.cz to CC for IPA related patches.
> 
> 2015-03-19 11:34 GMT+03:00 Ilya Enkovich <enkovich.gnu@gmail.com>:
> > On 12 Mar 13:27, Ilya Enkovich wrote:
> >> Hi,
> >>
> >> Currently cgraph merge has several issues with instrumented code:
> >>  - original function node may be removed => no assembler name conflict is detected between function and variable

Why do you need to detect this one?
> >>  - only orig_decl name is privatized for instrumented function => node still shares assembler name which causes infinite privatization loop
> >>  - information about changed name is stored in file_data of instrumented node => original section name may be not found for original function
> >>  - chkp reference is not fixed when nodes are merged
> >>
> >> This patch should fix theese problems by keeping instrumentation thunks reachable, privatizing both nodes and fixing chkp references.  Bootstrapped and tested on x86_64-unknown-linux-gnu.  OK for trunk?

Next stage1 I definitly hope we will be able to reduce number of special cases
we need for chck nodes.  I will try to read the code and your design document
and give it some tought.
> > 2015-03-19  Ilya Enkovich  <ilya.enkovich@intel.com>
> >
> >         * ipa-chkp.h (chkp_maybe_fix_chkp_ref): New.
> >         * ipa-chkp.c (chkp_maybe_fix_chkp_ref): New.
> >         * ipa.c (symbol_table::remove_unreachable_nodes): Don't
> >         remove instumentation thunks calling reachable functions.
> >         * lto-cgraph.c: Include ipa-chkp.h.
> >         (input_symtab): Fix chkp references for boundary nodes.
> >         * lto/lto-partition.c (privatize_symbol_name_1): New.
> >         (privatize_symbol_name): Privatize both decl and orig_decl
> >         names for instrumented functions.
> >         * lto/lto-symtab.c: Include ipa-chkp.h.
> >         (lto_cgraph_replace_node): Fix chkp references for merged
> >         function nodes.
> >
> > gcc/testsuite/
> >
> > 2015-03-19  Ilya Enkovich  <ilya.enkovich@intel.com>
> >
> >         * gcc.dg/lto/chkp-privatize-1_0.c: New.
> >         * gcc.dg/lto/chkp-privatize-1_1.c: New.
> >         * gcc.dg/lto/chkp-privatize-2_0.c: New.
> >         * gcc.dg/lto/chkp-privatize-2_1.c: New.
> >
> >
> > diff --git a/gcc/ipa-chkp.c b/gcc/ipa-chkp.c
> > index 0b857ff..7a7fc3c 100644
> > --- a/gcc/ipa-chkp.c
> > +++ b/gcc/ipa-chkp.c
> > @@ -414,6 +414,40 @@ chkp_instrumentable_p (tree fndecl)
> >           && (!fn || !copy_forbidden (fn, fndecl)));
> >  }
> >
> > +/* Check NODE has a correct IPA_REF_CHKP reference.
> > +   Create a new reference if required.  */
> > +
> > +void
> > +chkp_maybe_fix_chkp_ref (cgraph_node *node)

OK, so you have the chkp references that links to instrumented_version.
You do not stream them for boundary symbols but for some reason they are needed,
but when you can end up with wrong CHKP link?
> > diff --git a/gcc/ipa.c b/gcc/ipa.c
> > index b3752de..3054afe 100644
> > --- a/gcc/ipa.c
> > +++ b/gcc/ipa.c
> > @@ -492,7 +492,22 @@ symbol_table::remove_unreachable_nodes (FILE *file)
> >             }
> >           else if (cnode->thunk.thunk_p)
> >             enqueue_node (cnode->callees->callee, &first, &reachable);
> > -
> > +
> > +         /* For instrumentation clones we always need original
> > +            function node for proper LTO privatization.  */
> > +         if (cnode->instrumentation_clone
> > +             && reachable.contains (cnode)
> > +             && cnode->definition)
> > +           {
> > +             gcc_assert (cnode->instrumented_version || in_lto_p);
> > +             if (cnode->instrumented_version)
> > +               {
> > +                 enqueue_node (cnode->instrumented_version, &first,
> > +                               &reachable);
> > +                 reachable.add (cnode->instrumented_version);
> > +               }
> > +           }
> > +
This is OK
> > +/* Mangle NODE symbol name into a local name.
> > +   This is necessary to do
> > +   1) if two or more static vars of same assembler name
> > +      are merged into single ltrans unit.
> > +   2) if previously static var was promoted hidden to avoid possible conflict
> > +      with symbols defined out of the LTO world.  */
> > +
> > +static bool
> > +privatize_symbol_name (symtab_node *node)
> > +{
> > +  if (!privatize_symbol_name_1 (node, node->decl))
> > +    return false;
> > +
> >    /* We could change name which is a target of transparent alias
> >       chain of instrumented function name.  Fix alias chain if so  .*/
> > -  if (cnode)
> > +  if (cgraph_node *cnode = dyn_cast <cgraph_node *> (node))
> >      {
> >        tree iname = NULL_TREE;
> >        if (cnode->instrumentation_clone)
> > -       iname = DECL_ASSEMBLER_NAME (cnode->decl);
> > +       {
> > +         /* If we want to privatize instrumentation clone
> > +            then we also need to privatize original function.  */
> > +         if (cnode->instrumented_version)
> > +           privatize_symbol_name (cnode->instrumented_version);
> > +         else
> > +           privatize_symbol_name_1 (cnode, cnode->orig_decl);

This is because these are TRANSPARENT_ALIASes and thus visibility needs to match?
I plan to add generic support for transparent aliases soon (to fix the FORTIFY_SOURCE
LTO bug), so perhaps this will become easier?
THis is also OK.  We may want to have verifier code that checks that the visibility
match.

Honza

  reply	other threads:[~2015-04-02 17:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-12 12:10 Ilya Enkovich
2015-03-19  8:35 ` Ilya Enkovich
2015-04-02 14:52   ` Ilya Enkovich
2015-04-02 17:01     ` Jan Hubicka [this message]
2015-04-03  7:54       ` Ilya Enkovich
2015-04-03 18:49         ` Jan Hubicka
2015-04-06 13:57           ` Ilya Enkovich
2015-04-10  1:15             ` Jan Hubicka
2015-04-14  9:16               ` Ilya Enkovich
2015-05-05  8:06                 ` Ilya Enkovich
2015-05-19  9:40                   ` Ilya Enkovich
2015-05-26 13:09                     ` Ilya Enkovich
2015-05-29  6:33                       ` Jan Hubicka

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=20150402170115.GB21276@atrey.karlin.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=enkovich.gnu@gmail.com \
    --cc=gcc-patches@gcc.gnu.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).