From: Andi Kleen <ak@suse.de>
To: bidulock@openss7.org
Cc: Andrew Morton <akpm@osdl.org>,
adilger@clusterfs.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] use unlikely() for current_kernel_time() loop
Date: Thu, 8 Jun 2006 09:07:26 +0200 [thread overview]
Message-ID: <200606080907.26350.ak@suse.de> (raw)
In-Reply-To: <20060608010004.A12202@openss7.org>
On Thursday 08 June 2006 09:00, Brian F. G. Bidulock wrote:
> > Originally because it made assembly too unreadable. Later it was discovered
> > it produces smaller code too.
> >
>
> Thank you for the explanation. But, this brings to mind two other questions:
>
> Does the option not also make assembly less readable on other architectures?
Yes it does. Maybe the people who spend a lot of time debugging these
don't feel the pain anymore.
>
> If one is interested in smaller code, why not use -Os?
We already use -Os if you set the right config (but this change was actually
long before that)
It's possible that -Os includes -fno-block-reordering though.
> Also, does -fno-reorder-blocks actually defeat __builtin_expect()?
> (GCC documentation doesn't really say that.)
AFAIK gcc mostly uses the probability information for block reordering
to make the fast path fall through without jumps.
There are some more uses, but they don't impact the code very much.
-Andi
next prev parent reply other threads:[~2006-06-08 7:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-07 17:36 [PATCH] use unlikely() for current_kernel_time() loop Andreas Dilger
2006-06-08 2:28 ` Andi Kleen
2006-06-08 5:01 ` Andrew Morton
2006-06-08 5:39 ` Andi Kleen
2006-06-08 6:41 ` Brian F. G. Bidulock
2006-06-08 6:51 ` Andi Kleen
2006-06-08 7:00 ` Brian F. G. Bidulock
2006-06-08 7:07 ` Andi Kleen [this message]
2006-06-08 7:43 ` Brian F. G. Bidulock
2006-06-08 8:59 ` Brian F. G. Bidulock
2006-06-08 9:14 ` Andi Kleen
2006-06-08 9:36 ` Brian F. G. Bidulock
2006-06-08 10:20 ` Andi Kleen
2006-06-08 10:50 ` Brian F. G. Bidulock
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=200606080907.26350.ak@suse.de \
--to=ak@suse.de \
--cc=adilger@clusterfs.com \
--cc=akpm@osdl.org \
--cc=bidulock@openss7.org \
--cc=linux-kernel@vger.kernel.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