All of lore.kernel.org
 help / color / mirror / Atom feed
From: Albert Cahalan <albert@users.sf.net>
To: linux-kernel mailing list <linux-kernel@vger.kernel.org>
Cc: willy@w.ods.org, davem@redhat.com, jamie@shareable.org,
	chip@pobox.com, jamie@shareable.org, albert@users.sf.net
Subject: Re: [PATCH] 2.4.22pre10: {,un}likely_p() macros for pointers
Date: 10 Aug 2003 00:03:54 -0400	[thread overview]
Message-ID: <1060488233.780.65.camel@cube> (raw)

Willy Tarreau writes:
>On Sat, Aug 09, 2003 at 01:21:17AM +0100, Jamie Lokier wrote:
>> Albert Cahalan wrote:

>>> // tell gcc what to expect:   if(unlikely(err)) die(err);
>>> #define likely(x)       __builtin_expect(!!(x),1)
>>> #define unlikely(x)     __builtin_expect(!!(x),0)
>>> #define expected(x,y)   __builtin_expect((x),(y))
>>
>> You may want to check that GCC generates the same code as for
>>
>>  #define likely(x) __builtin_expect((x),1)
>>  #define unlikely(x) __builtin_expect((x),0)
>>
>> I tried this once, and I don't recall the precise result
>> but I do recall it generating different code (i.e. not
>> optimal for one of the definitions).

I looked at the assembly (ppc, gcc 3.2.3) and didn't
see any overhead.

Note that the kernel code is broken for the likely()
macro, since 42 is a perfectly good truth value in C.

> anyway, in __builtin_expect(!!(x),0) there is a useless
> conversion, because it's totally equivalent to
> __builtin_expect((x),0) (how could !!x be 0 if x isn't ?),
> but I'm pretty sure that the compiler will add the test.

The !!x gives you a 0 or 1 while converting the type.
So a (char*)0xfda9c80300000000ull will become a 1 of
an acceptable type, allowing the macro to work as desired.



             reply	other threads:[~2003-08-10  4:14 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-10  4:03 Albert Cahalan [this message]
2003-08-10  7:29 ` [PATCH] 2.4.22pre10: {,un}likely_p() macros for pointers Willy Tarreau
2003-08-10  8:02   ` Willy Tarreau
2003-08-11  1:23   ` Chip Salzenberg
2003-08-11  2:09     ` Jamie Lokier
2003-08-11  2:39       ` Chip Salzenberg
2003-08-11  4:02         ` Albert Cahalan
2003-08-11  4:30         ` Jamie Lokier
2003-08-11  5:30         ` Willy Tarreau
2003-08-11  5:42           ` Jamie Lokier
2003-08-11 13:09             ` Albert Cahalan
2003-08-11 18:55               ` Andrew Morton
2003-08-11 23:13                 ` Albert Cahalan
2003-08-13 19:42                   ` Jamie Lokier
2003-08-11  4:55   ` Jamie Lokier
2003-08-11  5:26     ` Willy Tarreau
2003-08-11  5:38       ` Jamie Lokier
  -- strict thread matches above, loose matches on Subject: below --
2003-08-05 12:44 Albert Cahalan
2003-08-09  0:21 ` Jamie Lokier
2003-08-09  8:13   ` Willy Tarreau
2003-08-09  8:51     ` David S. Miller
2003-08-09  9:36       ` Jamie Lokier
2003-08-09 10:10       ` Herbert Xu
2003-08-09 10:42       ` Alan Cox
2003-08-09 16:23         ` Jamie Lokier
2003-08-04 17:06 Chip Salzenberg

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=1060488233.780.65.camel@cube \
    --to=albert@users.sf.net \
    --cc=chip@pobox.com \
    --cc=davem@redhat.com \
    --cc=jamie@shareable.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=willy@w.ods.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 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.