Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

["J.A. Magallon" <jamagallon@able.es>]

[-- Attachment #1: Type: text/plain, Size: 2310 bytes --]


On 10.22, Joseph D. Wagner wrote:
> Yes, I know you can select Pentium III, Pentium 4, Athlon, etc, under 
> processor type when doing a 'make xconfig', but those selections do not 
> translate into the appropriate -mcpu and -march flags.
> 
> While the kernel on x86 architecture can be optimized in terms of generic 
> processor specifications (i.e. i386, i486, i586, i686), the kernel can't be 
> optimized beyond a i686.
> 
> If you select Pentium III, the -march flag is set to i686.
> If you select Pentium 4, the -march flag is set to i686.
> If you select Athlon 4, the -march flag is set to i686.
> If you select Athlon XP, the -march flag is set to i686.
> 
> It should be that...
> 
> If you select Pentium III, the -march flag is set to pentium3.
> If you select Pentium 4, the -march flag is set to pentium4.
> If you select Athlon 4, the -march flag is set to athlon-4.
> If you select Athlon XP, the -march flag is set to athlon-xp.
> 
> I don't want to have to hand edit the makefiles just to optimize my kernel.  
> I think this change is simple enough to do, and would allow kernel 
> developers the option of processor-specific optimizations in the future.
> 
> TIA.
> 
> Joseph D. Wagner

I have sent the attached patches sometimes to the list/Marcelo, and they
have been rejected to the moment because:
- gcc can spit some new instructions, reorganize code and other things when
  you jump from i686 to pentium3, for example.
- There can be bugs both in gcc and in the kernel that can be triggered by
  >i686 optimizations/code.
- This is not safe for a stable kernel, it was done in 2.5, bugs appeared,
  were corrected, and so on, 'cause this was a development kernel.

BTW, I use this regularly, and have not found any bugs, but I admit it is
unsafe. I also advocate for a pII split (I use a dual PII ;).
There are some other specific code that could be used in the kernel,
for example mb() and so on can be implemented with {m,s,l}fence in p3/p4
processors, instead of the old 'lock; insn' (attached also).

-- 
J.A. Magallon <jamagallon()able!es>     \                 Software is like sex:
werewolf!able!es                         \           It's better when it's free
Mandrake Linux release 9.2 (Cooker) for i586
Linux 2.4.23-pre7-jam2 (gcc 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk))

[-- Attachment #2: 22-x86-mb.bz2 --]
[-- Type: application/x-bzip, Size: 826 bytes --]