[Top] [All Lists]

Re: [PATCH v2] Alchemy: cpu feature override constants.

To: Manuel Lauss <>
Subject: Re: [PATCH v2] Alchemy: cpu feature override constants.
From: Ralf Baechle <>
Date: Wed, 26 Nov 2008 07:51:04 +0000
Cc: David Daney <>, LMO <>
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <>
User-agent: Mutt/1.5.18 (2008-05-17)
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.


<Prev in Thread] Current Thread [Next in Thread>