public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: Jeff Law <law@redhat.com>
Cc: Eric Gallager <egall@gwmail.gwu.edu>,
	gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: Add -Wsuggest-attribute=cold
Date: Mon, 24 Jul 2017 22:06:00 -0000	[thread overview]
Message-ID: <20170724220608.GA38863@kam.mff.cuni.cz> (raw)
In-Reply-To: <51047328-5f82-a57d-08c3-05432d0d2c98@redhat.com>

> On 07/24/2017 01:08 PM, Jan Hubicka wrote:
> >> On Mon, Jul 24, 2017 at 2:56 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
> >>> Hi,
> >>> this patch adds -Wsuggest-attribute=cold because we can now statically detect
> >>> cold functions atuomatically.
> >>>
> >>> Bootstrapped/regtested x86_64-linux. Plan to commit it tomorrow if there are no
> >>> complains.
> >>>
> >>> Honza
> >>>
> >>>         * invoke.texi (Wsuggest-attribute=cold): Document.
> >>>         * common.opt (Wsuggest-attribute=cold): New
> >>>         * ipa-pure-const.c (warn_function_cold): New function.
> >>>         * predict.c (compute_function_frequency): Use it.
> >>>         * predict.h (warn_function_cold): Declare.
> >>>
> >>>         * gcc.dg/cold-1.c: New testcase.
> >>
> >> Would it be possible to also do -Wsuggest-attribute=hot for symmetry's
> >> sake? Just wondering.
> > 
> > It would be nice, but it is kind of impossible to detect hot spots of the
> > program with reasonable certainity. (that is why profile feedback is useful :)
> > This cold attribute detection looks really for very simple pattern where the
> > function inavoidably calls other cold function or does something similarly
> > unlikely (Eh or trap).  This is fairly limited pattern, but it is useful i.e.
> > to detect which libstdc++ functions can have this annotation that further
> > improve branch prediction.
> So what's the advantage of a user adding the attribute if the compiler
> can infer it?  Presumably by adding the attribute, it's known without
> analysis and can be taken advantage of by its callers?

Like most of the other -Wsuggest it only warn on functions that are externally
visble. Adding attribute will improve code in other compilation units that does
not see the function body.

Honza
> Jeff

  reply	other threads:[~2017-07-24 22:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-24 18:56 Jan Hubicka
2017-07-24 19:02 ` Eric Gallager
2017-07-24 19:08   ` Jan Hubicka
2017-07-24 22:01     ` Jeff Law
2017-07-24 22:06       ` Jan Hubicka [this message]
2017-07-24 22:19         ` Jeff Law
2017-07-24 22:58 ` Martin Sebor
2017-10-09 11:42 ` Tom de Vries

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=20170724220608.GA38863@kam.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=egall@gwmail.gwu.edu \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=law@redhat.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).