Re: [PATCH 3/9] powerpc/4xx: Extended DCR support

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Mon, 2008-12-08 at 15:30 -0500, Josh Boyer wrote:

> Can we call this CPU_FTRS_440x6 please?  The H really has no relevance
> here from what I understand as both the hard and synthysized x6 cores
> would do the indexed instructions.

I'll change that.

> I'm wondering how much that is worth it.  Aren't you adding a
> runtime if here (and in the *dcri functions), which might
> impact performance for anything not implementing m*dcrx?
> 
> Does anyone know how much impact this has either way, and if
> it's significant could it be patched out after the CPU
> features are set?

So whatever the construct, gcc generates something quite horrible, on
the other hand, written like this is probably the less horrible I've
seen. The performance penalty shouldn't be huge, DCR accesses are slow.

Now, what we can/should do, but I'd rather do that from a separate patch
after you also cleanup that 440x5 stuff for machine check, is to be more
pro-active in cputable,h, at defining which 440 variants are effectively
enabled in Kconfig, and reflecting that in CPU_FTRS_POSSIBLE and
CPU_FTRS_ALWAYS.

That way, the cpu_has_feature() statement would be resolved at compile
time (either way) for all cases where only one variant of 440 is
compiled in (most cases). Only the case where support for multiple
variants is compiled in would result in the actual condition being in
the final code.

A way to do this is to define CONFIG_PPC_440x0, x5 and x6 and have those
be select'ed by the various SoC types which are themselves selected by
the platforms (I use x0 as "anything < x5" here). Then we can use these
to selectively or/and in thse various CPU features in cputable.h
"possible" and "always" masks.

So I'll resend the patch with just the 440H6->440x6 change and we'll do
those feature improvements in a separate patch.
 
Cheers,
Ben.