[PATCH] [2.4] [2.5] [i386] Add support for GCC 3.1 -march=pentium{-mmx,3,4}

[PATCH] [2.4] [2.5] [i386] Add support for GCC 3.1 -march=pentium{-mmx,3,4}

[Luca Barbieri]

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

This trival patch adds support for GCC 3.1 -march=pentium{-mmx,3,4}
option and applies to both 2.4 and 2.5.

--- linux-vanilla/arch/i386/Makefile	Wed Apr 10 14:37:33 2002
+++ linux/arch/i386/Makefile	Sat May 25 22:53:08 2002
@@ -43,7 +43,7 @@
 endif
 
 ifdef CONFIG_M586MMX
-CFLAGS += -march=i586
+CFLAGS += $(shell if $(CC) -march=pentium-mmx -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-march=pentium-mmx"; else echo "-march=i586"; fi)
 endif
 
 ifdef CONFIG_M686
@@ -51,11 +51,11 @@
 endif
 
 ifdef CONFIG_MPENTIUMIII
-CFLAGS += -march=i686
+CFLAGS += $(shell if $(CC) -march=pentium3 -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-march=pentium3"; else echo "-march=i686"; fi)
 endif
 
 ifdef CONFIG_MPENTIUM4
-CFLAGS += -march=i686
+CFLAGS += $(shell if $(CC) -march=pentium4 -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-march=pentium4"; else echo "-march=i686"; fi)
 endif
 
 ifdef CONFIG_MK6


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] [2.4] [2.5] [i386] Add support for GCC 3.1 -march=pentium{-mmx,3,4}

[Dave Jones]

On Sun, May 26, 2002 at 01:37:39AM +0200, J.A. Magallon wrote:
 > Could you also split 
 > 	Pentium-Pro/Celeron/Pentium-II     CONFIG_M686
 > into
 > 	
 > 	Pentium-Pro            CONFIG_M686
 > 	Pentium-II/Celeron     CONFIG_MPENTIUMII
 > 
 > Gcc-3.1 has also a -march=pentium2 specific target, that is not a synomym
 > for any other.

There are also a few extra Athlon targets iirc. athlon-xp and the like,
which I'm not sure the purpose of. Some gcc know-all want to clue me in
to what these offer over -march=athlon ?

 > BTW, I think an option to enable -mmmx would also be useful. Nothing more,
 > because afaik sse is only floating point.

Another interesting recently-added option which may be worth
benchmarking on modern CPUs is the prefetch-loops option.
In a lot of cases, the kernel 'knows better' and is adding the
prefetches itself, but it may be interesting to see what difference
gcc can make here. (More interesting would be examining the output to
see *where* gcc is putting the prefetches)

Given the immaturity of all these options, I'd doubt they're that good
an idea for 2.4. Getting them tested during 2.5 may prove to get any
bugs shaken out in time for $compiler_of_the_choice for 2.6 though.

    Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH] [2.4] [2.5] [i386] Add support for GCC 3.1 -march=pentium{-mmx,3,4}

[Luigi Genoni]

On Sun, 26 May 2002, Dave Jones wrote:

> On Sun, May 26, 2002 at 01:37:39AM +0200, J.A. Magallon wrote:
>  > Could you also split
>  > 	Pentium-Pro/Celeron/Pentium-II     CONFIG_M686
>  > into
>  >
>  > 	Pentium-Pro            CONFIG_M686
>  > 	Pentium-II/Celeron     CONFIG_MPENTIUMII
>  >
>  > Gcc-3.1 has also a -march=pentium2 specific target, that is not a synomym
>  > for any other.
>
> There are also a few extra Athlon targets iirc. athlon-xp and the like,
> which I'm not sure the purpose of. Some gcc know-all want to clue me in
> to what these offer over -march=athlon ?
>
I do not know about the gcc options, but Athlon XP/MP has sse instruction,
while tbird has not, so it could be relate to this.

>  > BTW, I think an option to enable -mmmx would also be useful. Nothing more,
>  > because afaik sse is only floating point.
>
> Another interesting recently-added option which may be worth
> benchmarking on modern CPUs is the prefetch-loops option.
> In a lot of cases, the kernel 'knows better' and is adding the
> prefetches itself, but it may be interesting to see what difference
> gcc can make here. (More interesting would be examining the output to
> see *where* gcc is putting the prefetches)
>
> Given the immaturity of all these options, I'd doubt they're that good
> an idea for 2.4. Getting them tested during 2.5 may prove to get any
> bugs shaken out in time for $compiler_of_the_choice for 2.6 though.
>
>     Dave
>
> --
> | Dave Jones.        http://www.codemonkey.org.uk
> | SuSE Labs
> -
> 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/
>

Re: [PATCH] [2.4] [2.5] [i386] Add support for GCC 3.1 -march=pentium{-mmx,3,4}

[J.A. Magallon]

On 2002.05.25 Luca Barbieri wrote:
>This trival patch adds support for GCC 3.1 -march=pentium{-mmx,3,4}
>option and applies to both 2.4 and 2.5.
>

Could you also split 
	Pentium-Pro/Celeron/Pentium-II     CONFIG_M686

into
	
	Pentium-Pro            CONFIG_M686
	Pentium-II/Celeron     CONFIG_MPENTIUMII

Gcc-3.1 has also a -march=pentium2 specific target, that is not a synomym
for any other.

BTW, I think an option to enable -mmmx would also be useful. Nothing more,
because afaik sse is only floating point.

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Mandrake Linux release 8.3 (Cooker) for i586
Linux werewolf 2.4.18 #1 SMP sáb may 25 14:44:46 CEST 2002 i686

Re: [PATCH] [2.4] [2.5] [i386] Add support for GCC 3.1 -march=pentium{-mmx,3,4}

[Ruth Ivimey-Cook]

On Sun, 26 May 2002, Luigi Genoni wrote:
>On Sun, 26 May 2002, Dave Jones wrote:
>> On Sun, May 26, 2002 at 01:37:39AM +0200, J.A. Magallon wrote:
>>  > Could you also split
>>  > 	Pentium-Pro/Celeron/Pentium-II     CONFIG_M686
>>  > into
>>  > 	Pentium-Pro            CONFIG_M686
>>  > 	Pentium-II/Celeron     CONFIG_MPENTIUMII
>> There are also a few extra Athlon targets iirc. athlon-xp and the like,
>> which I'm not sure the purpose of. Some gcc know-all want to clue me in
>> to what these offer over -march=athlon ?
>>
>I do not know about the gcc options, but Athlon XP/MP has sse instruction,
>while tbird has not, so it could be relate to this.
>
>>  > BTW, I think an option to enable -mmmx would also be useful. Nothing more,
>>  > because afaik sse is only floating point.

For the CONFIG_<<cputype>> options, is it only gcc compiler-type settings that 
are affected? I thought the assembly parts of the kernel were also switched on 
occasion.

I was wondering whether anyone has checked that these assembly snippets were 
decently optimal for the cpu type selected...


>> Another interesting recently-added option which may be worth
>> benchmarking on modern CPUs is the prefetch-loops option.
>> In a lot of cases, the kernel 'knows better' and is adding the

Be careful about 'knowing better' than compilers. I really don't want to start
a flamefest, but modern compilers are very good at doing all sorts of
optimisations, and hand-coded 'optimisations' can _sometimes_ actually hurt
performance over the unadorned version of the code. It is sensible to prove 
that the source-level optimisation helps, and then to mark it as such, so as 
compilers change it can be reviewed.


Regards,

Ruth

-- 
Ruth Ivimey-Cook
Software engineer and technical writer.

Re: [PATCH] [2.4] [2.5] [i386] Add support for GCC 3.1 -march=pentium{-mmx,3,4}

[Dave Jones]

On Sun, May 26, 2002 at 03:08:49AM +0200, J.A. Magallon wrote:
 > I think that the menu should contain separate config options for each
 > processor type, so it is easily modifiable for specific optimizations
 > offered by new compilers (for example, gcc-3.1 splitting i686 in
 > pentium-pro, p2, p3 and p4), or some braindead hacker can optimize
 > code snippets for some kind of processor.

Something like..

http://www.codemonkey.org.uk/patches/old/cpu-choice-2.diff
perhaps ? My original motivation wasn't so that we could fine grain the
compiler flags, but to cut down on the "my cpu wasn't in the list and
I didn't know which one to pick" bug reports.

I got sidetracked with something else though, which meant I never saw
this patch through to completion.. if theres any interest I'll pick it
up again.

    Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH] [2.4] [2.5] [i386] Add support for GCC 3.1 -march=pentium{-mmx,3,4}

[Dave Jones]

On Sun, May 26, 2002 at 12:49:57AM +0100, Ruth Ivimey-Cook wrote:

 > For the CONFIG_<<cputype>> options, is it only gcc compiler-type settings that 
 > are affected? I thought the assembly parts of the kernel were also switched on 
 > occasion.

Typically the MMX/3dnow/SSE memory copies get enabled where possible.

 > I was wondering whether anyone has checked that these assembly snippets were 
 > decently optimal for the cpu type selected...

Arjan and a few others spent weeks tuning the memset/memcpy functions,
there's really not that much room for improvement with them imo.
I spent a week or so a while back trying in vain to squeeze out just a
few more MB/s, and failed to get good results across the board.
There are a few tricks that can be pulled to do things like copying
backwards to trick hardware prefetchers, but this starts to get into
voodoo land.
For now, the i386 optimised memcpy is probably a closed book.
x86-64 may reopen that book to revisit some lessons learned..

 > > > In a lot of cases, the kernel 'knows better' and is adding the
 > Be careful about 'knowing better' than compilers. I really don't want to start
 > a flamefest, but modern compilers are very good at doing all sorts of
 > optimisations, and hand-coded 'optimisations' can _sometimes_ actually hurt
 > performance over the unadorned version of the code.
 
I would be (pleasantly) surprised to see gcc turn a C memcpy into faster
assembly than our current implementation. And I'll bet
$beverage_of_choice it'll stay that way for some time.
gcc has come on in leaps and bounds, but for something as performance
critical as memory copying/clearing, hand tuned assembly wins hands down.
Even AMD's/Intel's performance guides suggest doing this. It's the only
way to fly.
 
    Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH] [2.4] [2.5] [i386] Add support for GCC 3.1 -march=pentium{-mmx,3,4}

[J.A. Magallon]

On 2002.05.26 Ruth Ivimey-Cook wrote:
>On Sun, 26 May 2002, Luigi Genoni wrote:
>>On Sun, 26 May 2002, Dave Jones wrote:
>>> On Sun, May 26, 2002 at 01:37:39AM +0200, J.A. Magallon wrote:
>>>  > Could you also split
>>>  > 	Pentium-Pro/Celeron/Pentium-II     CONFIG_M686
>>>  > into
>>>  > 	Pentium-Pro            CONFIG_M686
>>>  > 	Pentium-II/Celeron     CONFIG_MPENTIUMII
>>> There are also a few extra Athlon targets iirc. athlon-xp and the like,
>>> which I'm not sure the purpose of. Some gcc know-all want to clue me in
>>> to what these offer over -march=athlon ?
>>>
>>I do not know about the gcc options, but Athlon XP/MP has sse instruction,
>>while tbird has not, so it could be relate to this.
>>

Problem is that CPU selection is not based on cpu itself, but in options
offered by previous gcc compilers.

I think that the menu should contain separate config options for each
processor type, so it is easily modifiable for specific optimizations
offered by new compilers (for example, gcc-3.1 splitting i686 in
pentium-pro, p2, p3 and p4), or some braindead hacker can optimize
code snippets for some kind of processor.

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Mandrake Linux release 8.3 (Cooker) for i586
Linux werewolf 2.4.18 #1 SMP sáb may 25 14:44:46 CEST 2002 i686

Re: [PATCH] [2.4] [2.5] [i386] Add support for GCC 3.1 -march=pentium{-mmx,3,4}

[J.A. Magallon]

On 2002.05.26 Alan Cox wrote:
>On Sun, 2002-05-26 at 00:37, J.A. Magallon wrote:
>> Gcc-3.1 has also a -march=pentium2 specific target, that is not a synomym
>> for any other.
>> 
>
>Splitting PII from PPro is a good move for another reason. The PPro
>requires a locked spin_unlock due to an errata - the PII seems not to. 
>

So I can kill CONFIG_X86_PPRO_FENCE for a PII ? If yes, I will try.

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Mandrake Linux release 8.3 (Cooker) for i586
Linux werewolf 2.4.19-pre8-jam4 #1 SMP dom may 26 02:36:58 CEST 2002 i686

Re: [PATCH] [2.4] [2.5] [i386] Add support for GCC 3.1 -march=pentium{-mmx,3,4}

[Alan Cox]

On Sun, 2002-05-26 at 10:11, J.A. Magallon wrote:
> >Splitting PII from PPro is a good move for another reason. The PPro
> >requires a locked spin_unlock due to an errata - the PII seems not to. 
> >
> 
> So I can kill CONFIG_X86_PPRO_FENCE for a PII ? If yes, I will try.

As I understand the errata involved yes you can. If so please make sure
the  PII specific kernel panics on a ppro because subtle locking failure
is not a pleasant result when someone runs the wrong kernel.

PII specific also means you can assume MMX is present which may be
useful in future page copying accelerations

Re: [PATCH] [2.4] [2.5] [i386] Add support for GCC 3.1 -march=pentium{-mmx,3,4}

[Pavel Machek]

Hi!

> I would be (pleasantly) surprised to see gcc turn a C memcpy into faster
> assembly than our current implementation. And I'll bet

gcc has hand-coded assembly inside itself, if gcc compiled memcpy is slower
than hand-optimized one, you found a compiler bug.

>  it'll stay that way for some time.
> gcc has come on in leaps and bounds, but for something as performance
> critical as memory copying/clearing, hand tuned assembly wins hands down.
> Even AMD's/Intel's performance guides suggest doing this. It's the only
> way to fly.

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: [PATCH] [2.4] [2.5] [i386] Add support for GCC 3.1 -march=pentium{-mmx,3,4}

[Dave Jones]

On Mon, May 27, 2002 at 08:53:02AM +0000, Pavel Machek wrote:
 > Hi!
 > 
 > > I would be (pleasantly) surprised to see gcc turn a C memcpy into faster
 > > assembly than our current implementation. And I'll bet
 > 
 > gcc has hand-coded assembly inside itself, if gcc compiled memcpy is slower
 > than hand-optimized one, you found a compiler bug.

Not at all. gcc compiled memcpy just has no knowledge of things like
non-temporal stores, and using mmx/sse to move 64 bits at a time instead
of 32 bit registers. (It's only recently it got prefetch abilities too).

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH] [2.4] [2.5] [i386] Add support for GCC 3.1 -march=pentium{-mmx,3,4}

[Pavel Machek]

Hi!

>  > > I would be (pleasantly) surprised to see gcc turn a C memcpy into faster
>  > > assembly than our current implementation. And I'll bet
>  > 
>  > gcc has hand-coded assembly inside itself, if gcc compiled memcpy is slower
>  > than hand-optimized one, you found a compiler bug.
> 
> Not at all. gcc compiled memcpy just has no knowledge of things like
> non-temporal stores, and using mmx/sse to move 64 bits at a time

non-temporal stores are bypassing cache? Is it always good idea?

> instead
> of 32 bit registers. (It's only recently it got prefetch abilities
> too).

gcc knows about mmx/sse, and could decide to use it.
									Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: [PATCH] [2.4] [2.5] [i386] Add support for GCC 3.1 -march=pentium{-mmx,3,4}

[Jan Hubicka]

> Hi!
> 
> >  > > I would be (pleasantly) surprised to see gcc turn a C memcpy into faster
> >  > > assembly than our current implementation. And I'll bet
> >  > 
> >  > gcc has hand-coded assembly inside itself, if gcc compiled memcpy is slower
> >  > than hand-optimized one, you found a compiler bug.
> > 
> > Not at all. gcc compiled memcpy just has no knowledge of things like
> > non-temporal stores, and using mmx/sse to move 64 bits at a time
> 
> non-temporal stores are bypassing cache? Is it always good idea?

The strategy GCC uses is to emit memcpy/memset for short blocks and call
function for others expecting that the function will contain all nasty
tricks possible.  For large blocks this is a win concerning code size
bloat caused by inlining MMX loops.

Nontemporal stores is definitly win for large blocks that does not fit
into cache as a whole, I am not sure whether this is the case of kernel.
I think kernel itself is usually zeroing memory just before it is used,
but I may be mistaken.
> 
> > instead
> > of 32 bit registers. (It's only recently it got prefetch abilities
> > too).
> 
> gcc knows about mmx/sse, and could decide to use it.

I don't do that at the moment.  I am thinking about teaching it to use
SSE moves for moving/clearing 64bit and larger values in memory.
(ie for inlining constantly sized string operations)

Honza
> 									Pavel
> -- 
> Casualities in World Trade Center: ~3k dead inside the building,
> cryptography in U.S.A. and free speech in Czech Republic.

Re: [PATCH] [2.4] [2.5] [i386] Add support for GCC 3.1 -march=pentium{-mmx,3,4}

[David Woodhouse]

jh@suse.cz said:
>  I don't do that at the moment.  I am thinking about teaching it to
> use SSE moves for moving/clearing 64bit and larger values in memory.
> (ie for inlining constantly sized string operations)

Please ensure that we get -mno-implicit-fp and/or -mno-implicit-sse options 
to GCC _long_ before there's any chance of actually _needing_ to use them 
to get a correct kernel compile.

--
dwmw2

Re: [PATCH] [2.4] [2.5] [i386] Add support for GCC 3.1 -march=pentium{-mmx,3,4}

[Jan Hubicka]

> 
> jh@suse.cz said:
> >  I don't do that at the moment.  I am thinking about teaching it to
> > use SSE moves for moving/clearing 64bit and larger values in memory.
> > (ie for inlining constantly sized string operations)
> 
> Please ensure that we get -mno-implicit-fp and/or -mno-implicit-sse options 
> to GCC _long_ before there's any chance of actually _needing_ to use them 
> to get a correct kernel compile.

I am keeping this in mind.  Unfortunately we are running into command
line options explossion.  We already do have -msse, -msse2,
-mfpamath=sse/i387/sse,i387
all affecting in nontrivial way the compilation.  I would like to
implement SSE based string functions and SSE based integer arithmetics
soon, later we may want to use SSE for complex numbers and
autovectorization.  We may want to use MMX when the register files are
split and 3dNOW as alternative for float arithmetics.

By adding option for each such feature, soon we will run out of
oppurtunities to test them all to be functional :(

Honza
> 
> --
> dwmw2
>