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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
