public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: PING: [PATCH v2] tree-profile: Don't instrument an IFUNC resolver nor its callees
Date: Tue, 2 Apr 2024 19:03:27 +0200	[thread overview]
Message-ID: <Zgw6X36Pq7qNO3FE@kam.mff.cuni.cz> (raw)
In-Reply-To: <CAMe9rOpukwZui401ou-_t9kGLfsccujdsFJM9BDVJH2KOjUJ1A@mail.gmail.com>

> > I am bit worried about commonly used functions getting "infected" by
> > being called once from ifunc resolver.  I think we only use thread local
> > storage for indirect call profiling, so we may just disable indirect
> > call profiling for these functions.
> 
> Will change it.
> 
> > Also the patch will be noop with -flto -flto-partition=max, so probably
> > we need to compute this flag at WPA time and stream to partitions.
> >
> 
> Why is it a nop with -flto -flto-partition=max? I got
> 
> (gdb) bt
> #0  symtab_node::check_ifunc_callee_symtab_nodes ()
>     at /export/gnu/import/git/gitlab/x86-gcc/gcc/symtab.cc:1440
> #1  0x0000000000e487d3 in symbol_table::compile (this=0x7fffea006000)
>     at /export/gnu/import/git/gitlab/x86-gcc/gcc/cgraphunit.cc:2320
> #2  0x0000000000d23ecf in lto_main ()
>     at /export/gnu/import/git/gitlab/x86-gcc/gcc/lto/lto.cc:687
> #3  0x00000000015254d2 in compile_file ()
>     at /export/gnu/import/git/gitlab/x86-gcc/gcc/toplev.cc:449
> #4  0x00000000015284a4 in do_compile ()
>     at /export/gnu/import/git/gitlab/x86-gcc/gcc/toplev.cc:2154
> #5  0x0000000001528864 in toplev::main (this=0x7fffffffd84a, argc=16,
>     argv=0x42261f0) at /export/gnu/import/git/gitlab/x86-gcc/gcc/toplev.cc:2310
> #6  0x00000000030a3fe2 in main (argc=16, argv=0x7fffffffd958)
>     at /export/gnu/import/git/gitlab/x86-gcc/gcc/main.cc:39
> 
> Do you have a testcase to show that it is a nop?
Aha, sorry.  I tought this is run during late optimization, but it is
done early, so LTo partitioning does not mix things up.  So current
patch modified to disable only instrumentation that needs TLS should be
fine.

Honza
> 
> -- 
> H.J.

  reply	other threads:[~2024-04-02 17:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-05 21:45 H.J. Lu
2024-04-02 14:41 ` PING: " H.J. Lu
2024-04-02 14:50   ` Jan Hubicka
2024-04-02 15:57     ` H.J. Lu
2024-04-02 17:03       ` Jan Hubicka [this message]
2024-04-03 12:41         ` H.J. Lu

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=Zgw6X36Pq7qNO3FE@kam.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hjl.tools@gmail.com \
    /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).