From: der.herr@hofr.at (Nicholas Mc Guire)
To: kernelnewbies@lists.kernelnewbies.org
Subject: unlikely compiler flag propagation
Date: Wed, 18 Feb 2015 19:38:01 +0100 [thread overview]
Message-ID: <20150218183801.GA1773@opentech.at> (raw)
In-Reply-To: <20150218182453.GB21740@kroah.com>
On Wed, 18 Feb 2015, Greg KH wrote:
> On Wed, Feb 18, 2015 at 07:09:47PM +0100, Matthias Brugger wrote:
> > Hi all,
> >
> > I have a question about the unlikely compiler flag.
> > When a called function is only returns an error with the unlikely flag
> > set, should I set the unlikely compiler flag for the return value
> > check in the callee as well?
> >
> > For example:
> >
> > int function_one(int *list, int num_elements)
> > {
> > int i;
> > for (i =0; i < num_elements; i++) {
> > if (unlikely(check_element(list + i)))
> > return 1;
> > }
> >
> > [...]
> >
> > return 0;
> > }
> >
> > int function_two(...)
> > {
> > [...]
> >
> > if (function_one(list, num))
> > return -1;
> > }
> >
> >
> > So my question is, if function_two should instead implement:
> > if (unlikely(function_one(list, num))
> >
> > Or does the unlikely compiler flag propagate to calling functions?
>
> NEVER use unlikely/likely unless you can actually measure that it
> matters if you use it. The compiler and processor is almost always
> better at making these types of guesses and predictions, so let it do
> the work instead.
>
> As proof of this, there was a test of the kernel a year or so ago that
> measured the placement of the existing likely/unlikely markers in the
> kernel and 90% of the usages were wrong and actually slowed down the
> processor.
>
interesting - would you have a reference to some talk/paper/data/... ?
> So just don't use it, unless you can measure it.
>
thx!
hofrat
next prev parent reply other threads:[~2015-02-18 18:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-18 18:09 unlikely compiler flag propagation Matthias Brugger
2015-02-18 18:24 ` Greg KH
2015-02-18 18:35 ` Matthias Brugger
2015-02-18 19:02 ` Greg KH
2015-02-18 18:38 ` Nicholas Mc Guire [this message]
2015-02-18 18:57 ` Valdis.Kletnieks at vt.edu
2015-02-18 19:02 ` Nicholas Mc Guire
2015-02-19 11:34 ` Anupam Kapoor
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=20150218183801.GA1773@opentech.at \
--to=der.herr@hofr.at \
--cc=kernelnewbies@lists.kernelnewbies.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 NNTP newsgroup(s).