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: Jan Hubicka <hubicka@ucw.cz>, gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [CHKP, PATCH] Fix LTO cgraph merge for instrumented functions
Date: Fri, 29 May 2015 06:33:00 -0000	[thread overview]
Message-ID: <20150529051337.GA21936@kam.mff.cuni.cz> (raw)
In-Reply-To: <CAMbmDYb9=99hRQrWOPRzfP7TOFjZdZ1sSFmmNE-Dhd9MuhSEug@mail.gmail.com>

> Ping

I am really sorry for ignoring this so long - I would like to reorg the code
and replace instrumentaiton thunks by the notion of transparent aliases,
but did not have time to do that yet.  Have quite busy time now.
> >>>
> >>> 2015-04-14  Ilya Enkovich  <ilya.enkovich@intel.com>
> >>>
> >>>         * ipa.c (symbol_table::remove_unreachable_nodes): Don't
> >>>         remove instumentation thunks calling reachable functions.
> >>>         * lto-cgraph.c (output_refs): Always output IPA_REF_CHKP.
> >>>         * lto/lto-partition.c (privatize_symbol_name_1): New.
> >>>         (privatize_symbol_name): Privatize both decl and orig_decl
> >>>         names for instrumented functions.
> >>>
> >>> gcc/testsuite/
> >>>
> >>> 2015-04-14  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.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)

reachable.contains (cnode) is !in_boundary_p.

> >>> +             && 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);

Why do you need the other tests.  Can we have instrumentation node that is not definition?
I suppose you can remove if (cnode->instrumented_version) because you assert it anyway.

> >>> -  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);
> >>> +         iname = DECL_ASSEMBLER_NAME (cnode->decl);
> >>> +         TREE_CHAIN (iname) = DECL_ASSEMBLER_NAME (cnode->orig_decl);
> >>> +       }
> >>>        else if (cnode->instrumented_version
> >>> -              && cnode->instrumented_version->orig_decl == decl)
> >>> -       iname = DECL_ASSEMBLER_NAME (cnode->instrumented_version->decl);
> >>> -
> >>> -      if (iname)
> >>> +              && cnode->instrumented_version->orig_decl == cnode->decl)
> >>>         {
> >>> -         gcc_assert (IDENTIFIER_TRANSPARENT_ALIAS (iname));
> >>> -         TREE_CHAIN (iname) = DECL_ASSEMBLER_NAME (decl);
> >>> +         iname = DECL_ASSEMBLER_NAME (cnode->instrumented_version->decl);
> >>> +         TREE_CHAIN (iname) = DECL_ASSEMBLER_NAME (cnode->decl);
> >>>         }
> >>>      }
> >>> -  if (symtab->dump_file)
> >>> -    fprintf (symtab->dump_file,
> >>> -           "Privatizing symbol name: %s -> %s\n",
> >>> -           name, IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)));
> >>> +

I think we ought to have verify_symtab_node checking for this.  All the handling of the
name links seems somewhat fragile (I am mostly concerned about getting it right for
LTO before remaning takes place)

OK with the changes above for mainline and for branch if it does not cause problems
for a week.

Honza
> >>>    return true;
> >>>  }
> >>>
> >>> diff --git a/gcc/testsuite/gcc.dg/lto/chkp-privatize-1_0.c b/gcc/testsuite/gcc.dg/lto/chkp-privatize-1_0.c
> >>> new file mode 100644
> >>> index 0000000..2054aa15
> >>> --- /dev/null
> >>> +++ b/gcc/testsuite/gcc.dg/lto/chkp-privatize-1_0.c
> >>> @@ -0,0 +1,17 @@
> >>> +/* { dg-lto-do link } */
> >>> +/* { dg-require-effective-target mpx } */
> >>> +/* { dg-lto-options { { -Ofast -flto -fcheck-pointer-bounds -mmpx } } } */
> >>> +
> >>> +extern int __attribute__((noinline)) f1 (int i);
> >>> +
> >>> +static int __attribute__((noinline))
> >>> +f2 (int i)
> >>> +{
> >>> +  return i + 6;
> >>> +}
> >>> +
> >>> +int
> >>> +main (int argc, char **argv)
> >>> +{
> >>> +  return f1 (argc) + f2 (argc);
> >>> +}
> >>> diff --git a/gcc/testsuite/gcc.dg/lto/chkp-privatize-1_1.c b/gcc/testsuite/gcc.dg/lto/chkp-privatize-1_1.c
> >>> new file mode 100644
> >>> index 0000000..4fa8656
> >>> --- /dev/null
> >>> +++ b/gcc/testsuite/gcc.dg/lto/chkp-privatize-1_1.c
> >>> @@ -0,0 +1,11 @@
> >>> +static int __attribute__((noinline))
> >>> +f2 (int i)
> >>> +{
> >>> +  return 2 * i;
> >>> +}
> >>> +
> >>> +int __attribute__((noinline))
> >>> +f1 (int i)
> >>> +{
> >>> +  return f2 (i) + 10;
> >>> +}
> >>> diff --git a/gcc/testsuite/gcc.dg/lto/chkp-privatize-2_0.c b/gcc/testsuite/gcc.dg/lto/chkp-privatize-2_0.c
> >>> new file mode 100644
> >>> index 0000000..be7f601
> >>> --- /dev/null
> >>> +++ b/gcc/testsuite/gcc.dg/lto/chkp-privatize-2_0.c
> >>> @@ -0,0 +1,18 @@
> >>> +/* { dg-lto-do link } */
> >>> +/* { dg-require-effective-target mpx } */
> >>> +/* { dg-lto-options { { -Ofast -flto -fcheck-pointer-bounds -mmpx } } } */
> >>> +
> >>> +static int
> >>> +__attribute__ ((noinline))
> >>> +func1 (int i)
> >>> +{
> >>> +  return i + 2;
> >>> +}
> >>> +
> >>> +extern int func2 (int i);
> >>> +
> >>> +int
> >>> +main (int argc, char **argv)
> >>> +{
> >>> +  return func1 (argc) + func2 (argc) + 1;
> >>> +}
> >>> diff --git a/gcc/testsuite/gcc.dg/lto/chkp-privatize-2_1.c b/gcc/testsuite/gcc.dg/lto/chkp-privatize-2_1.c
> >>> new file mode 100644
> >>> index 0000000..db39e7f
> >>> --- /dev/null
> >>> +++ b/gcc/testsuite/gcc.dg/lto/chkp-privatize-2_1.c
> >>> @@ -0,0 +1,8 @@
> >>> +int func1 = 10;
> >>> +
> >>> +int
> >>> +func2 (int i)
> >>> +{
> >>> +  func1++;
> >>> +  return i + func1;
> >>> +}

      reply	other threads:[~2015-05-29  5:13 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
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 [this message]

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=20150529051337.GA21936@kam.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).