All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: Steve French <smfrench@gmail.com>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Re: optimizing out inline functions
Date: Wed, 28 May 2008 22:00:57 +0200	[thread overview]
Message-ID: <20080528200057.GA7300@uranus.ravnborg.org> (raw)
In-Reply-To: <524f69650805281251r1b1d99a1tc3223d15e3aeb50c@mail.gmail.com>

On Wed, May 28, 2008 at 02:51:02PM -0500, Steve French wrote:
> In trying to remove some macros, I ran across another kernel style
> question.  I see two ways that people try to let the compiler optimize
> out unused code and would like to know which is preferred.  The first
> example uses an empty inline function and trusts the compiler will
> optimize it out.
> 
> #ifdef CONFIG_DEBUG_SOMETHING
> static inline void some_debug_function(var1)
> {
>     something = var1;
>     printk(some debug text);
> }
> #else
> static inline void some_debug_function(var1)
> {
>    /* empty function */
> }
> #endif

With reference to a recent thread about kconfig
I would prefer:
static inline void some_debug_function(var1)
{
	if (KCONFIG_DEBUG_SOMETHING) {
		something = var1;
		printk(some debug text);
	}
}


But we do not have KCONFIG_DEBUG_SOMETHING available
so the second best is to use an empty function
to keep the typechecking in place.

IIRC gcc optimize both away.

	Sam

  parent reply	other threads:[~2008-05-28 20:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-28 19:51 optimizing out inline functions Steve French
2008-05-28 19:54 ` Pekka Enberg
2008-05-29  8:40   ` Andrew Morton
2008-05-28 20:00 ` Sam Ravnborg [this message]
2008-05-29 16:39   ` Steve French
2008-05-29 17:20     ` Sam Ravnborg
2008-06-02  9:38     ` Vegard Nossum
     [not found] <ayzYV-7mv-5@gated-at.bofh.it>
     [not found] ` <ayA8E-89e-29@gated-at.bofh.it>
2008-05-28 20:37   ` James Kosin
2008-05-29  3:27     ` Johannes Weiner
2008-05-29  3:04       ` Joe Perches
2008-05-29 13:11       ` James Kosin
2008-05-29 13:13       ` James Kosin

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=20080528200057.GA7300@uranus.ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=smfrench@gmail.com \
    /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.