[2.4] [2.5] [i386] Add support for GCC 3.1 -march=pentium{-mmx,3,4}
PATCH 1/1 [2.4] [2.5] [i386] Add support for GCC 3.1 -march=pentium{-mmx,3,4}
This trival patch adds support for GCC 3.1 -march=pentium{-mmx,3,4} option and applies to both 2.4 and 2.5.
arch/i386/Makefile +3 -3
@@ -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
Quoted 3 lines · 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.
Signature · 4 lines
J.A. Magallon # Let the source be with you... mailto:[email protected] 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
Quoted 9 lines · J.A. Magallon
Could you also split
Pentium-Pro/Celeron/Pentium-IICONFIG_M686
intoPentium-Pro
CONFIG_M686
Pentium-II/CeleronCONFIG_MPENTIUMIIGcc-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 ?
Quoted 2 lines
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
Signature · 2 lines
| Dave Jones. http://www.codemonkey.org.uk | SuSE Labs
Quoted 8 lines · Dave Jones
Quoted 7 lines · J.A. Magallon
Could you also split
Pentium-Pro/Celeron/Pentium-IICONFIG_M686
intoPentium-Pro
CONFIG_M686
Pentium-II/CeleronCONFIG_MPENTIUMII
Quoted 7 lines
Quoted 2 lines
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.
Quoted 25 lines
Quoted 2 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 11 lines · Luigi Genoni
Quoted 10 lines · Dave Jones
Quoted 5 lines · J.A. Magallon
Could you also split
Pentium-Pro/Celeron/Pentium-IICONFIG_M686
into
Pentium-ProCONFIG_M686
Pentium-II/CeleronCONFIG_MPENTIUMIIThere 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 ?
Quoted 5 lines
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.
Quoted 2 lines
Quoted 2 lines
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...
Quoted 3 lines
Quoted 3 lines
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
Signature · 2 lines
Ruth Ivimey-Cook Software engineer and technical writer.
Quoted 12 lines · On 2002.05.26 Ruth Ivimey-Cook wrote:
Quoted 11 lines · Luigi Genoni
Quoted 10 lines · Dave Jones
Quoted 5 lines · J.A. Magallon
Could you also split
Pentium-Pro/Celeron/Pentium-IICONFIG_M686
into
Pentium-ProCONFIG_M686
Pentium-II/CeleronCONFIG_MPENTIUMIIThere 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 ?
Quoted 3 lines
Quoted 3 lines
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.
Signature · 4 lines
J.A. Magallon # Let the source be with you... mailto:[email protected] 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
Quoted 5 lines · J.A. Magallon
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.
Signature · 2 lines
| Dave Jones. http://www.codemonkey.org.uk | SuSE Labs
Quoted 3 lines · Ruth Ivimey-Cook
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.
Quoted 2 lines
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..
Quoted 5 lines
Quoted 1 line
Quoted 1 line
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.
Signature · 2 lines
| Dave Jones. http://www.codemonkey.org.uk | SuSE Labs
Hi!
Quoted 2 lines
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.
Quoted 5 lines
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.
Signature · 2 lines
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Quoted 7 lines · Pavel Machek
Hi!
Quoted 2 lines
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).
Signature · 2 lines
| Dave Jones. http://www.codemonkey.org.uk | SuSE Labs
Hi!
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
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?
Quoted 3 lines
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
Signature · 2 lines
Casualities in World Trade Center: ~3k dead inside the building, cryptography in U.S.A. and free speech in Czech Republic.
Quoted 5 lines
Hi!
Quoted 3 lines
Quoted 3 lines
Quoted 2 lines
I would be (pleasantly) surprised to see gcc turn a C memcpy into faster assembly than our current implementation. And I'll bet
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
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.
Quoted 6 lines
Quoted 4 lines
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
Quoted 4 lines
Pavel
Signature · 2 lines
Casualities in World Trade Center: ~3k dead inside the building, cryptography in U.S.A. and free speech in Czech Republic.
Quoted 3 lines · [email protected] 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
Quoted 9 lines
Quoted 3 lines · [email protected] 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
Quoted 4 lines
--
dwmw2
Quoted 8 lines · On 2002.05.26 Alan Cox wrote:
Quoted 3 lines · J.A. Magallon
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_unlockdue to an errata - the PII seems not to.
So I can kill CONFIG_X86_PPRO_FENCE for a PII ? If yes, I will try.
Signature · 4 lines
J.A. Magallon # Let the source be with you... mailto:[email protected] 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
Quoted 5 lines · J.A. Magallon
Quoted 3 lines
Splitting PII from PPro is a good move for another reason. The PPro requires a locked
spin_unlockdue to an errata - the PII seems not to.So I can kill
CONFIG_X86_PPRO_FENCEfor 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