All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Daniel Walker <dwalker@fifo99.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: Mon, 14 Sep 2009 10:43:51 +0400	[thread overview]
Message-ID: <20090914064351.GA4190@lenovo> (raw)
In-Reply-To: <alpine.LFD.2.00.0909122336330.12448@eddie.linux-mips.org>

[Maciej W. Rozycki - Sat, Sep 12, 2009 at 11:51:40PM +0100]
| 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
| 

Actually this is quite a good candidate for commit message :)

	-- Cyrill

  reply	other threads:[~2009-09-14  6:43 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
2009-09-14  6:43       ` Cyrill Gorcunov [this message]
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=20090914064351.GA4190@lenovo \
    --to=gorcunov@gmail.com \
    --cc=dwalker@fifo99.com \
    --cc=julia@diku.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@linux-mips.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.