Linus Torvalds wrote:
quoted text
> 
> On Mon, 8 Sep 2008, H. Peter Anvin wrote:
>>  
>>  config X86_GENERIC
>> -	bool "Generic x86 support"
>> +	bool "Generic x86 support" if EMBEDDED
> 
> Ok, so after having realized that this seems to be more about a bug with 
> gcc, I'm really not as convinced any more.
> 
> As far as I can tell, there are three issues:
> 
>  - "-mtune=core/core2/pentium4/.." is buggy in some gas/gcc versions on 
>    x86-32, and makes architectural choices.
> 
>    Any actual _released_ versions? Maybe it's just a current SVN issue?

binutils-2.18.50.0.6-5, which is the current version on Fedora 9, does this.

quoted text
>    Workaround: don't use it. And yes, X86_GENERIC=y will do that, although 
>    quite frankly that seems to be dubious in itself. But quite frankly, 
>    it's a gcc bug, and we should see it as such.
> 
>    The better workaround may well be "-Wa,-mtune=generic" as you pointed 
>    out.
> 
>  - We do the CONFIG_P6_NOPL thing ourselves, and we should just stop 
>    doing that on 32-bit. There simply isn't a good enough reason to do so. 
>    I already posteed the Kconfig.cpu patch to just stop doing it.

As far as I can tell, -Wa,-mtune=generic *should* work.  It doesn't look 
to me as if cc1 will generate the long NOPs.  That one we can do 
unconditionally, of course.

quoted text
>  - X86_GENERIC means _other_ things too, like doing a 128-bit cacheline 
>    just so that it won't suck horribly on P4's even if it's otherwise 
>    tuned for a good microarchitecture.
> 
> And they really do seem to be _separate_ issues. Do we really want to tie 
> these things together under X86_GENERIC? 

Well, the argument in favour would be that if you want a kernel that can 
cross between different microarchitectures, then you want the "don't 
suck horribly on any of them".  We can, of course, divide them down 
further, but is it useful?

The "ideal" way to do any of this would probably to have checkboxes for 
all the CPUs you want to support and then a drop-down box for the CPU to 
optimize for.  However, the combinatorics of that would be horrible, and 
it would be very unlikely we would avoid bugs.

	-hpa
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/