linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Kumar Gala <kumar.gala@freescale.com>
Cc: linuxppc-dev@ozlabs.org, pantelis.antoniou@gmail.com,
	linuxppc64-dev@ozlabs.org, linuxppc-embedded@ozlabs.org
Subject: Re: [PATCH] powerpc: merge include/asm/cputable.h
Date: Fri, 16 Sep 2005 05:11:38 +0200	[thread overview]
Message-ID: <200509160511.39277.arnd@arndb.de> (raw)
In-Reply-To: <D6BA4E97-B338-4584-8ECD-440FC70AFED0@freescale.com>

On Freedag 16 September 2005 04:22, Kumar Gala wrote:

> > #define CPU_FTR_POSSIBLE CPU_FTR_PSERIES_POSSIBLE |  
> > CPU_FTR_PMAC_POSSIBLE \
> >          | CPU_FTR_...
> > #define CPU_FTR_ALWAYS CPU_FTR_POSSIBLE & CPU_FTR_PSERIES_ALWAYS \
> >         & CPU_FTR_PMAC_ALWAYS & CPU_FTR_ ...
> 
> Yes, something like that.  Why do we need the CPU_FTR_ALWAYS.  It  
> seems that CPU_FTR_POSSIBLE is sufficient.  I may just not understand  
> the purpose of CPU_FTR_ALWAYS.
>
> > One point to consider is that we traditionally use #ifdef in the
> > source for many places that could simply use cpu_has_feature(). E.g.
> > most instances of #ifdef CONFIG_ALTIVEC could be replaced by
> > cpu_has_feature(CPU_FTR_ALTIVEC) without additional run-time overhead.
> 
> These should stay as CONFIG options because to reduce the code size  
> of the kernel which is important to embedded people.

The whole point of the logic is to reduce code size, because gcc
is smart enough to remove all dead code then.
Consider again the definition of

| static inline int have_feature(unsigned long feature)
| {
|      return (FEATURE_ALWAYS & feature) ||
|             (FEATURE_POSSIBLE & runtime_feature & feature);
| }

If the feature is part of FEATURE_ALWAYS, this will be optimized to

|      return 1 || FEATURE_POSSIBLE & runtime_feature & feature;

and subsequently

|      return 1;

If it is not part of FEATURE_POSSIBLE, it it equivalent to

|      return 0 || (0 & runtime_feature & feature);

which becomes

|      return 0;


Any code inside of

|      if (0) { /* ... */ }

is only checked for syntax by gcc but will not end up in the object code.
For the 'if(1)' case, the code gets smaller as well, because the runtime
flag does not have to be dereferenced.

For some places, we might prefer to replace '#ifdef CONFIG_FOO' not with
have_feature(FOO), but rather with feature_possible(FOO), given a definition
of 

static inline int have_feature(unsigned int feature)
{
	return !!(FEATURE_POSSIBLE & feature);
}

which always get evaluated at compile time.

	Arnd <><

  reply	other threads:[~2005-09-16  3:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-08 21:02 cpu features testing 32 vs 64 bit Becky Bruce
2005-09-08 21:08 ` Pantelis Antoniou
2005-09-08 21:20   ` Kumar Gala
2005-09-08 21:48     ` Dan Malek
2005-09-08 22:02       ` Kumar Gala
2005-09-08 22:20         ` Dan Malek
2005-09-08 22:36         ` Arnd Bergmann
2005-09-09  0:08           ` David Gibson
2005-09-09  4:23           ` [PATCH] powerpc: merge include/asm/cputable.h Arnd Bergmann
2005-09-14 19:11             ` Kumar Gala
2005-09-14 23:58               ` Arnd Bergmann
2005-09-15 17:44                 ` Kumar Gala
2005-09-15 22:56                   ` Arnd Bergmann
2005-09-16  2:22                     ` Kumar Gala
2005-09-16  3:11                       ` Arnd Bergmann [this message]
2005-09-16 21:40                         ` Kumar Gala
2005-09-17  0:36                           ` Arnd Bergmann
2005-09-09 22:19     ` cpu features testing 32 vs 64 bit Benjamin Herrenschmidt

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=200509160511.39277.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=kumar.gala@freescale.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=linuxppc64-dev@ozlabs.org \
    --cc=pantelis.antoniou@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).