All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Daniel Walker <dwalker@fifo99.com>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>, Ingo Molnar <mingo@elte.hu>,
	Julia Lawall <julia@diku.dk>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86: apic: convert BUG() to BUG_ON()
Date: Sat, 12 Sep 2009 23:51:40 +0100 (BST)	[thread overview]
Message-ID: <alpine.LFD.2.00.0909122336330.12448@eddie.linux-mips.org> (raw)
In-Reply-To: <1252779641.28368.81.camel@desktop>

On Sat, 12 Sep 2009, Daniel Walker wrote:

> For one it condenses duplicate code (i.e. the if()). If the BUG_ON()
> macro gets updated with something new, all the users get the updates
> automatically. The other thing is your re-using potentially more
> advanced code that's inside the macro. In this case it's fairly trivial,
> 
> #define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while(0)
> 
> So we're getting the benefit on the new "unlikely" in the apic code.
> unlikely/likely calls will usually allow the compiler to create smaller,
> and or, more optimized code. 

 For non-x86 platforms the use of the BUG_ON() macro may result in more 
efficient code GCC may not be able to optimise to with if (...) BUG();.  
For example the macro may expand to inline assembly with a conditional 
trap instruction GCC would not emit for an if () clause.  While GCC does 
have a __builtin_trap() intrinsic that could be optimised if alone in a 
conditional block, such usage may not be frequent enough for a dedicated 
optimisation to be provided and build-time efficiency of the compiler does 
matter too, so such an optimisation might be of too questionable a value 
to incur an additional performance hit for the compiler.

 Just a general note on patches of this kind, or to put it short, yes I 
agree it's a good idea.

  Maciej

  parent reply	other threads:[~2009-09-12 22:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-12 17:40 [PATCH] x86: apic: convert BUG() to BUG_ON() Daniel Walker
2009-09-12 18:05 ` Cyrill Gorcunov
2009-09-12 18:20   ` Daniel Walker
2009-09-12 18:49     ` Cyrill Gorcunov
2009-09-12 22:51     ` Maciej W. Rozycki [this message]
2009-09-14  6:43       ` Cyrill Gorcunov
2009-09-18 11:48 ` [tip:x86/urgent] x86: apic: Convert " tip-bot for Daniel Walker

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=alpine.LFD.2.00.0909122336330.12448@eddie.linux-mips.org \
    --to=macro@linux-mips.org \
    --cc=dwalker@fifo99.com \
    --cc=gorcunov@gmail.com \
    --cc=julia@diku.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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.