All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Manuel Lauss <mano@roarinelk.homelinux.net>
Cc: David Daney <ddaney@caviumnetworks.com>, LMO <linux-mips@linux-mips.org>
Subject: Re: [PATCH v2] Alchemy: cpu feature override constants.
Date: Wed, 26 Nov 2008 07:51:04 +0000	[thread overview]
Message-ID: <20081126075103.GA4232@linux-mips.org> (raw)
In-Reply-To: <20081126055053.GA12831@roarinelk.homelinux.net>

On Wed, Nov 26, 2008 at 06:50:53AM +0100, Manuel Lauss wrote:

> > The probe routines in cpu-probe.c should get at least some of that correct. 
> >  How about just overriding the things that cpu-probe.c doesn't get right?
> 
> CPU detection gets them all right, it's just that somehow GCC does not use
> the information correctly;  i.e. in the __fls() case it blindly falls back
> on the C version instead of using the asm macro with clz in it.  I scanned
> a few callsites of __fls() and there's not 'clz' to be found anywhere.  With
> this addition the clz is used and the binary is a _lot_ smaller.
> 

You should define all values as constants, as far as known.  GCC will
then be able to use constant propagation and dead code elemination to
optimize the code for a particular target system.

The way fls() is written it will only use of CLZ if the expression
cpu_has_mips_r is a constant, that is if the kernel is being built
exclusivly for MIPS32 / MIPS64 revision 1 or higher.  The reason that
__fls is written this way is that both it's legacy and R1 variants using
CLZ/DCLZ the function body will be compiled into something relativly small.
There is not such much point in adding even more code for a runtime
decission between two variants.

> I believe this is a gcc thing, but this seemed to be the obvious quick
> remedy.

GCC does correct.

  Ralf

  reply	other threads:[~2008-11-26  7:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-25 23:12 [PATCH v2] Alchemy: cpu feature override constants Manuel Lauss
2008-11-25 23:23 ` David Daney
2008-11-26  5:50   ` Manuel Lauss
2008-11-26  7:51     ` Ralf Baechle [this message]
2008-11-26  8:08       ` Manuel Lauss
2008-11-26  8:34         ` Ralf Baechle
2008-11-26 12:48 ` Sergei Shtylyov

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=20081126075103.GA4232@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=ddaney@caviumnetworks.com \
    --cc=linux-mips@linux-mips.org \
    --cc=mano@roarinelk.homelinux.net \
    /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.