From: Michael Ellerman <michael@ellerman.id.au>
To: Adrian Bunk <bunk@kernel.org>
Cc: Roel Kluin <12o3l@tiscali.nl>,
lkml <linux-kernel@vger.kernel.org>,
cbe-oss-dev@ozlabs.org, linuxppc-dev@ozlabs.org,
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>,
Willy Tarreau <w@1wt.eu>, Arjan van de Ven <arjan@infradead.org>
Subject: Re: [PATCH 1/3] Fix Unlikely(x) == y
Date: Tue, 19 Feb 2008 08:46:03 +1100 [thread overview]
Message-ID: <1203371163.6844.2.camel@concordia> (raw)
In-Reply-To: <20080218141340.GB667@cs181133002.pp.htv.fi>
[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]
On Mon, 2008-02-18 at 16:13 +0200, Adrian Bunk wrote:
> On Mon, Feb 18, 2008 at 03:01:35PM +0100, Geert Uytterhoeven wrote:
> > On Mon, 18 Feb 2008, Adrian Bunk wrote:
> > >
> > > This means it generates faster code with a current gcc for your platform.
> > >
> > > But a future gcc might e.g. replace the whole loop with a division
> > > (gcc SVN head (that will soon become gcc 4.3) already does
> > > transformations like replacing loops with divisions [1]).
> >
> > Hence shouldn't we ask the gcc people what's the purpose of __builtin_expect(),
> > if it doesn't live up to its promise?
>
> That's a different issue.
>
> My point here is that we do not know how the latest gcc available in the
> year 2010 might transform this code, and how a likely/unlikely placed
> there might influence gcc's optimizations then.
You're right, we don't know. But if giving the compiler _more_
information causes it to produce vastly inferior code then we should be
filing gcc bugs. After all the unlikely/likely is just a hint, if gcc
knows better it can always ignore it.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <michael@ellerman.id.au>
To: Adrian Bunk <bunk@kernel.org>
Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>,
Roel Kluin <12o3l@tiscali.nl>,
lkml <linux-kernel@vger.kernel.org>,
cbe-oss-dev@ozlabs.org, linuxppc-dev@ozlabs.org,
Willy Tarreau <w@1wt.eu>, Arjan van de Ven <arjan@infradead.org>
Subject: Re: [PATCH 1/3] Fix Unlikely(x) == y
Date: Tue, 19 Feb 2008 08:46:03 +1100 [thread overview]
Message-ID: <1203371163.6844.2.camel@concordia> (raw)
In-Reply-To: <20080218141340.GB667@cs181133002.pp.htv.fi>
[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]
On Mon, 2008-02-18 at 16:13 +0200, Adrian Bunk wrote:
> On Mon, Feb 18, 2008 at 03:01:35PM +0100, Geert Uytterhoeven wrote:
> > On Mon, 18 Feb 2008, Adrian Bunk wrote:
> > >
> > > This means it generates faster code with a current gcc for your platform.
> > >
> > > But a future gcc might e.g. replace the whole loop with a division
> > > (gcc SVN head (that will soon become gcc 4.3) already does
> > > transformations like replacing loops with divisions [1]).
> >
> > Hence shouldn't we ask the gcc people what's the purpose of __builtin_expect(),
> > if it doesn't live up to its promise?
>
> That's a different issue.
>
> My point here is that we do not know how the latest gcc available in the
> year 2010 might transform this code, and how a likely/unlikely placed
> there might influence gcc's optimizations then.
You're right, we don't know. But if giving the compiler _more_
information causes it to produce vastly inferior code then we should be
filing gcc bugs. After all the unlikely/likely is just a hint, if gcc
knows better it can always ignore it.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2008-02-18 21:46 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-16 16:08 [PATCH 1/3] Fix Unlikely(x) == y Roel Kluin
2008-02-16 17:25 ` Arjan van de Ven
2008-02-16 17:25 ` Arjan van de Ven
2008-02-16 17:33 ` Willy Tarreau
2008-02-16 17:33 ` Willy Tarreau
2008-02-16 17:42 ` Arjan van de Ven
2008-02-16 17:42 ` Arjan van de Ven
2008-02-16 17:58 ` Willy Tarreau
2008-02-16 17:58 ` Willy Tarreau
2008-02-16 18:29 ` Arjan van de Ven
2008-02-16 18:29 ` Arjan van de Ven
2008-02-17 9:45 ` [Cbe-oss-dev] " Andrew Pinski
2008-02-17 9:45 ` Andrew Pinski
2008-02-17 10:08 ` Willy Tarreau
2008-02-17 10:08 ` Willy Tarreau
2008-02-16 18:31 ` Geoff Levand
2008-02-16 18:31 ` Geoff Levand
2008-02-16 18:39 ` Arjan van de Ven
2008-02-16 18:39 ` Arjan van de Ven
2008-02-17 11:50 ` Michael Ellerman
2008-02-17 11:50 ` Michael Ellerman
2008-02-18 13:56 ` Adrian Bunk
2008-02-18 13:56 ` Adrian Bunk
2008-02-18 14:01 ` Geert Uytterhoeven
2008-02-18 14:01 ` Geert Uytterhoeven
2008-02-18 14:13 ` Adrian Bunk
2008-02-18 14:13 ` Adrian Bunk
2008-02-18 21:46 ` Michael Ellerman [this message]
2008-02-18 21:46 ` Michael Ellerman
2008-02-19 7:43 ` Adrian Bunk
2008-02-19 7:43 ` Adrian Bunk
2008-02-18 14:27 ` David Howells
2008-02-18 14:27 ` David Howells
2008-02-18 14:59 ` Roel Kluin
2008-02-18 14:59 ` Roel Kluin
2008-02-18 18:11 ` Valdis.Kletnieks
2008-02-18 18:11 ` Valdis.Kletnieks
2008-02-18 18:33 ` Arjan van de Ven
2008-02-18 18:33 ` Arjan van de Ven
2008-02-18 19:22 ` [Cbe-oss-dev] " Andrew Pinski
2008-02-18 14:39 ` Andi Kleen
2008-02-18 14:39 ` Andi Kleen
2008-02-19 2:33 ` Nick Piggin
2008-02-19 2:33 ` Nick Piggin
2008-02-19 2:40 ` Arjan van de Ven
2008-02-19 2:40 ` Arjan van de Ven
2008-02-19 4:41 ` Nick Piggin
2008-02-19 4:41 ` Nick Piggin
2008-02-19 5:58 ` Willy Tarreau
2008-02-19 5:58 ` Willy Tarreau
2008-02-19 6:20 ` Nick Piggin
2008-02-19 6:20 ` Nick Piggin
2008-02-19 9:28 ` Andi Kleen
2008-02-19 9:28 ` Andi Kleen
2008-02-20 7:32 ` Willy Tarreau
2008-02-20 7:32 ` Willy Tarreau
2008-02-19 9:25 ` Andi Kleen
2008-02-19 9:25 ` Andi Kleen
2008-02-19 9:46 ` Nick Piggin
2008-02-19 9:46 ` Nick Piggin
2008-02-19 9:57 ` Andi Kleen
2008-02-19 9:57 ` Andi Kleen
2008-02-19 22:25 ` Nick Piggin
2008-02-19 22:25 ` Nick Piggin
2008-02-16 18:41 ` Geoff Levand
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=1203371163.6844.2.camel@concordia \
--to=michael@ellerman.id.au \
--cc=12o3l@tiscali.nl \
--cc=Geert.Uytterhoeven@sonycom.com \
--cc=arjan@infradead.org \
--cc=bunk@kernel.org \
--cc=cbe-oss-dev@ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=w@1wt.eu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.