* Loop unrolling-related SPEC regressions? @ 2002-02-01 10:32 Paolo Carlini 2002-02-01 10:46 ` Richard Henderson 2002-02-01 11:14 ` Joe Buck 0 siblings, 2 replies; 41+ messages in thread From: Paolo Carlini @ 2002-02-01 10:32 UTC (permalink / raw) To: gcc; +Cc: rth Hi, browsing the latest results from Andreas, it looks like a few of them (e.g., 164.gzip, 186.crafty, 200.sixtrack) are showing a definite regression in the PEAK case, characterized by -funroll-all-loops. May it be related to the recent: http://gcc.gnu.org/ml/gcc-patches/2002-01/msg02199.html ?? Thanks, Paolo. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-01 10:32 Loop unrolling-related SPEC regressions? Paolo Carlini @ 2002-02-01 10:46 ` Richard Henderson 2002-02-01 10:51 ` Paolo Carlini 2002-02-01 11:14 ` Joe Buck 1 sibling, 1 reply; 41+ messages in thread From: Richard Henderson @ 2002-02-01 10:46 UTC (permalink / raw) To: Paolo Carlini; +Cc: gcc > browsing the latest results from Andreas, it looks like a few of them (e.g., > 164.gzip, 186.crafty, 200.sixtrack) are showing a definite regression in the > PEAK case, characterized by -funroll-all-loops. May it be related to the > recent: Possibly. If someone debugs this and finds a test case for which loop unrolling fails where it succeeded before, I'll look at it. I can't promise to fix it though, since the fix may break the original test case. r~ ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-01 10:46 ` Richard Henderson @ 2002-02-01 10:51 ` Paolo Carlini 2002-02-01 10:57 ` Richard Henderson 0 siblings, 1 reply; 41+ messages in thread From: Paolo Carlini @ 2002-02-01 10:51 UTC (permalink / raw) To: Richard Henderson; +Cc: aj, gcc Richard Henderson wrote: > > browsing the latest results from Andreas, it looks like a few of them (e.g., > > 164.gzip, 186.crafty, 200.sixtrack) are showing a definite regression in the > > PEAK case, characterized by -funroll-all-loops. May it be related to the > > recent: > > Possibly. If someone debugs this and finds a test case for which loop > unrolling fails where it succeeded before, I'll look at it. Thanks for your prompt reply. The problem is, all of SPEC is not publicly available :-( Only Andreas may try to heavily distil a testcase from the original codes... Otherwise, we should find one somewhere else. Where?? > I can't > promise to fix it though, since the fix may break the original test case. I see. Cheers, P. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-01 10:51 ` Paolo Carlini @ 2002-02-01 10:57 ` Richard Henderson 2002-02-01 11:12 ` Paolo Carlini 0 siblings, 1 reply; 41+ messages in thread From: Richard Henderson @ 2002-02-01 10:57 UTC (permalink / raw) To: Paolo Carlini; +Cc: aj, gcc On Fri, Feb 01, 2002 at 07:50:03PM +0100, Paolo Carlini wrote: > Otherwise, we should find one somewhere else. Where?? There are other benchmarks. Some of them are on gcc.gnu.org somewhere (there's a link off the web pages). Try them and see if we regress -funroll-loops. Note that I have no confidence that -funroll-all-loops is a useful thing to try. You're overriding the logic in the unroller that tries to decide if the unrolling would pay off. r~ ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-01 10:57 ` Richard Henderson @ 2002-02-01 11:12 ` Paolo Carlini 2002-02-04 8:37 ` Andreas Jaeger 0 siblings, 1 reply; 41+ messages in thread From: Paolo Carlini @ 2002-02-01 11:12 UTC (permalink / raw) To: Richard Henderson; +Cc: gcc, aj Richard Henderson wrote: > On Fri, Feb 01, 2002 at 07:50:03PM +0100, Paolo Carlini wrote: > > Otherwise, we should find one somewhere else. Where?? > > There are other benchmarks. Some of them are on gcc.gnu.org > somewhere (there's a link off the web pages). Try them and > see if we regress -funroll-loops. Ok. I will try to do my best during the weekend. > Note that I have no confidence that -funroll-all-loops is a > useful thing to try. You're overriding the logic in the > unroller that tries to decide if the unrolling would pay off. I see. Perhaps we could ask Andreas to help by running an exceptional SPEC test with -funroll-loops instead (ideally, 2 different runs, pre- and post- the unroller patch). Cheers, Paolo. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-01 11:12 ` Paolo Carlini @ 2002-02-04 8:37 ` Andreas Jaeger 2002-02-04 9:05 ` Paolo Carlini 0 siblings, 1 reply; 41+ messages in thread From: Andreas Jaeger @ 2002-02-04 8:37 UTC (permalink / raw) To: Paolo Carlini; +Cc: Richard Henderson, gcc Paolo Carlini <pcarlini@unitus.it> writes: > Perhaps we could ask Andreas to help by running an exceptional SPEC test with > -funroll-loops instead (ideally, 2 different runs, pre- and post- the unroller > patch). Sorry for joining in late, I've been travelling. Tell me exactly which patch I should revert and which compiler flags I should use and I'll bootstrap two GCCs and run one SPECint run using the different compilers for base and peak. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-04 8:37 ` Andreas Jaeger @ 2002-02-04 9:05 ` Paolo Carlini 2002-02-04 11:15 ` Andreas Jaeger 2002-02-06 0:59 ` Andreas Jaeger 0 siblings, 2 replies; 41+ messages in thread From: Paolo Carlini @ 2002-02-04 9:05 UTC (permalink / raw) To: Andreas Jaeger; +Cc: gcc, rth Andreas Jaeger wrote: >Paolo Carlini <pcarlini@unitus.it> writes: > >>Perhaps we could ask Andreas to help by running an exceptional SPEC test with >>-funroll-loops instead (ideally, 2 different runs, pre- and post- the unroller >>patch). >> >Sorry for joining in late, I've been travelling. > >Tell me exactly which patch I should revert and which compiler flags I >should use and I'll bootstrap two GCCs and run one SPECint run using >the different compilers for base and peak. > Thank you very much for your feedback Andreas. With your help we could try to understand the following: RTH patch affects negatively SPEC runs (*) for a PEAK setup identical to that which you currently use *but* with -funroll-loops (instead of -funroll-all-loops) or not? In the process, we could also understand more of the issue itself -funroll-all-loops vs. -funroll-loops. Therefore, if you agree, this is the patch which should be tentatively reverted: http://gcc.gnu.org/ml/gcc-patches/2002-01/msg02199.html Thanks, Paolo. (*) When I say "affect negatively" I really mean the following: there is a good amount of evidence that due to that patch the following tests loose many points: 164.gzip, 186.crafty, 200.sixtrack. > > >Andreas > -- Paolo Carlini Dipartimento di Scienze Ambientali Università degli Studi della Tuscia Largo dell'Università , I-01100, Viterbo, ITALY ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-04 9:05 ` Paolo Carlini @ 2002-02-04 11:15 ` Andreas Jaeger 2002-02-06 0:59 ` Andreas Jaeger 1 sibling, 0 replies; 41+ messages in thread From: Andreas Jaeger @ 2002-02-04 11:15 UTC (permalink / raw) To: Paolo Carlini; +Cc: gcc, rth Paolo Carlini <pcarlini@unitus.it> writes: > Andreas Jaeger wrote: > >>Paolo Carlini <pcarlini@unitus.it> writes: >> >>>Perhaps we could ask Andreas to help by running an exceptional SPEC test with >>>-funroll-loops instead (ideally, 2 different runs, pre- and post- the unroller >>>patch). >>> >>Sorry for joining in late, I've been travelling. >> >>Tell me exactly which patch I should revert and which compiler flags I >>should use and I'll bootstrap two GCCs and run one SPECint run using >>the different compilers for base and peak. >> > Thank you very much for your feedback Andreas. > With your help we could try to understand the following: RTH patch > affects negatively SPEC runs (*) for a PEAK setup identical to that > which you currently use *but* with -funroll-loops (instead of > -funroll-all-loops) or not? In the process, we could also understand > more of the issue itself -funroll-all-loops vs. -funroll-loops. > Therefore, if you agree, this is the patch which should be tentatively > reverted: > > http://gcc.gnu.org/ml/gcc-patches/2002-01/msg02199.html > > Thanks, > Paolo. > > (*) When I say "affect negatively" I really mean the following: there > is a good amount of evidence that due to that patch the following > tests loose many points: 164.gzip, 186.crafty, 200.sixtrack. I have some scripts [1] that bootstrap GCC and automatically run SPEC. I'll try to setup some tests tomorrow and send the results, Andreas Footnotes: [1] If anybody likes to have my scripts, just ask me. -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-04 9:05 ` Paolo Carlini 2002-02-04 11:15 ` Andreas Jaeger @ 2002-02-06 0:59 ` Andreas Jaeger 2002-02-06 1:05 ` Paolo Carlini 2002-02-06 13:08 ` Andreas Jaeger 1 sibling, 2 replies; 41+ messages in thread From: Andreas Jaeger @ 2002-02-06 0:59 UTC (permalink / raw) To: Paolo Carlini; +Cc: gcc, rth [-- Attachment #1: Type: text/plain, Size: 388 bytes --] Here're the results of: Base Compiler: GCC CVS as of Feb 5 2002 8am UTC Peak Compiler: base plus reversion of loop unrolling patch cflags base: -fomit-frame-pointer -march=athlon -funroll-loops -fstrict-aliasing -malign-double cflags peak: -fomit-frame-pointer -march=athlon -funroll-loops -fstrict-aliasing -malign-double Iterations: 3 Tell me if you like to see other runs, Andreas [-- Attachment #2: CINT2000.010.asc --] [-- Type: text/plain, Size: 7228 bytes --] ############################################################################## # INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN # # # # 'reportable' flag not set during run # # # # INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN # ############################################################################## SPEC CINT2000 Summary Unknown Unknown Tested by SuSE GmbH Tue Feb 5 10:02:30 2002 SPEC License #1922 Test date: 2002-02-05 Hardware availability: June 2001 Tester: Andreas Jaeger, SuSE GmbH Software availability: Now Estimated Estimated Base Base Base Peak Peak Peak Benchmarks Ref Time Run Time Ratio Ref Time Run Time Ratio ------------ -------- -------- -------- -------- -------- -------- 164.gzip 1400 562 249 1400 560 250 164.gzip 1400 561 250* 1400 559 250* 164.gzip 1400 559 251 1400 559 251 175.vpr 1400 700 200* 1400 699 200* 175.vpr 1400 701 200 1400 700 200 175.vpr 1400 699 200 1400 699 200 176.gcc 1100 449 245 1100 451 244* 176.gcc 1100 450 244 1100 451 244 176.gcc 1100 449 245* 1100 451 244 181.mcf 1800 1048 172* 1800 1048 172 181.mcf 1800 1048 172 1800 1045 172 181.mcf 1800 1047 172 1800 1047 172* 186.crafty 1000 279 358* 1000 279 358* 186.crafty 1000 279 358 1000 279 358 186.crafty 1000 279 358 1000 279 358 197.parser 1800 795 226 1800 796 226 197.parser 1800 795 226 1800 795 226 197.parser 1800 795 226* 1800 796 226* 252.eon 1300 983 132 1300 983 132 252.eon 1300 983 132* 1300 983 132* 252.eon 1300 984 132 1300 983 132 253.perlbmk 1800 592 304 1800 592 304 253.perlbmk 1800 592 304 1800 592 304* 253.perlbmk 1800 592 304* 1800 592 304 254.gap 1100 526 209 1100 525 209 254.gap 1100 525 210 1100 525 209* 254.gap 1100 525 209* 1100 525 210 255.vortex 1900 595 319* 1900 595 319* 255.vortex 1900 597 318 1900 596 319 255.vortex 1900 595 319 1900 595 319 256.bzip2 1500 827 181 1500 827 181 256.bzip2 1500 826 182 1500 826 182 256.bzip2 1500 826 182* 1500 826 182* 300.twolf 3000 1327 226 3000 1329 226 300.twolf 3000 1334 225 3000 1340 224* 300.twolf 3000 1329 226* 3000 1341 224 ======================================================================== 164.gzip 1400 561 250* 1400 559 250* 175.vpr 1400 700 200* 1400 699 200* 176.gcc 1100 449 245* 1100 451 244* 181.mcf 1800 1048 172* 1800 1047 172* 186.crafty 1000 279 358* 1000 279 358* 197.parser 1800 795 226* 1800 796 226* 252.eon 1300 983 132* 1300 983 132* 253.perlbmk 1800 592 304* 1800 592 304* 254.gap 1100 525 209* 1100 525 209* 255.vortex 1900 595 319* 1900 595 319* 256.bzip2 1500 826 182* 1500 826 182* 300.twolf 3000 1329 226* 3000 1340 224* Est. SPECint_base2000 227 Est. SPECint2000 227 HARDWARE -------- Hardware Vendor: Unknown Model Name: Unknown CPU: AMD Athlon(tm) Processor CPU MHz: 1102.541 FPU: Integrated CPU(s) enabled: 1 CPU(s) orderable: 1 Parallel: No Primary Cache: Secondary Cache: 256 KB L3 Cache: N/A Other Cache: N/A Memory: 496 MB Disk Subsystem: Unknown Other Hardware: Ethernet SOFTWARE -------- Operating System: SuSE Linux 7.3 (i386) Compiler: GCC CVS File System: Linux/ReiserFS System State: Multi-User NOTES ----- Base flags: -fomit-frame-pointer -march=athlon -funroll-loops -fstrict-aliasing -malign-double base plus reversion of loop unrolling patch Peak flags: -fomit-frame-pointer -march=athlon -funroll-loops -fstrict-aliasing -malign-double Unspecified To compile and execute eon correctly the following extra flags are used for compilation: -ffast-math -fwritable-strings. ############################################################################## # INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN # # # # 'reportable' flag not set during run # # # # INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN # ############################################################################## ----------------------------------------------------------------------------- For questions about this result, please contact the tester. For other inquiries, please contact webmaster@spec.org. Copyright 1999-2000 Standard Performance Evaluation Corporation Generated on Wed Feb 6 00:44:09 2002 by SPEC CPU2000 ASCII formatter v2.1 [-- Attachment #3: Type: text/plain, Size: 100 bytes --] -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-06 0:59 ` Andreas Jaeger @ 2002-02-06 1:05 ` Paolo Carlini 2002-02-06 1:39 ` Andreas Jaeger 2002-02-06 13:08 ` Andreas Jaeger 1 sibling, 1 reply; 41+ messages in thread From: Paolo Carlini @ 2002-02-06 1:05 UTC (permalink / raw) To: Andreas Jaeger; +Cc: gcc, rth Andreas Jaeger wrote: >Tell me if you like to see other runs, > Thank you very much, Andreas. >164.gzip 1400 561 250* 1400 559 250* > >186.crafty 1000 279 358* 1000 279 358* > Really indistinguishable, right? >Est. SPECint_base2000 227 > Est. SPECint2000 227 > Andreas, please excuse my *very* stupid question (for sure I could find this explained somewhere in your pages ;-) How these SPEC indexes compare with those you publish on the WEB? I mean they are roughly half in size. Thanks, Paolo. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-06 1:05 ` Paolo Carlini @ 2002-02-06 1:39 ` Andreas Jaeger 2002-02-06 1:43 ` Paolo Carlini 0 siblings, 1 reply; 41+ messages in thread From: Andreas Jaeger @ 2002-02-06 1:39 UTC (permalink / raw) To: Paolo Carlini; +Cc: gcc, rth Paolo Carlini <pcarlini@unitus.it> writes: > Andreas Jaeger wrote: > >>Tell me if you like to see other runs, >> > Thank you very much, Andreas. > >>164.gzip 1400 561 250* 1400 559 250* >> >>186.crafty 1000 279 358* 1000 279 358* >> > Really indistinguishable, right? Yes. >>Est. SPECint_base2000 227 >> Est. SPECint2000 227 >> > Andreas, please excuse my *very* stupid question (for sure I could > find this explained somewhere in your pages ;-) > How these SPEC indexes compare with those you publish on the WEB? I > mean they are roughly half in size. Let's check... Oh, it's a different machine it's the one I use for: http://www.suse.de/%7Eaj/SPEC/CINT/sandbox/index.html But nevertheless the numbers look wrong... I found it - I forgot to add -O3 :-( Ok, I rerun the tests with correct flags now: cflags base: -O3 -fomit-frame-pointer -march=athlon -funroll-loops -fstrict-aliasing -malign-double cflags peak: -O3 -fomit-frame-pointer -march=athlon -funroll-loops -fstrict-aliasing -malign-double Sorry - and thanks for looking closer into these... Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-06 1:39 ` Andreas Jaeger @ 2002-02-06 1:43 ` Paolo Carlini 2002-02-06 1:43 ` Andreas Jaeger 2002-02-06 1:50 ` Andreas Jaeger 0 siblings, 2 replies; 41+ messages in thread From: Paolo Carlini @ 2002-02-06 1:43 UTC (permalink / raw) To: Andreas Jaeger; +Cc: gcc Andreas Jaeger wrote: >I found it - I forgot to add -O3 :-( > >Ok, I rerun the tests with correct flags now: >cflags base: -O3 -fomit-frame-pointer -march=athlon -funroll-loops -fstrict-aliasing -malign-double >cflags peak: -O3 -fomit-frame-pointer -march=athlon -funroll-loops -fstrict-aliasing -malign-double > >Sorry - and thanks for looking closer into these... > Ok :-) Any chance you can run also SPECfp2000 (at least 200.sixtrack) ??? Thanks, Paolo. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-06 1:43 ` Paolo Carlini @ 2002-02-06 1:43 ` Andreas Jaeger 2002-02-06 1:50 ` Andreas Jaeger 1 sibling, 0 replies; 41+ messages in thread From: Andreas Jaeger @ 2002-02-06 1:43 UTC (permalink / raw) To: Paolo Carlini; +Cc: gcc Paolo Carlini <pcarlini@unitus.it> writes: > Andreas Jaeger wrote: > >>I found it - I forgot to add -O3 :-( >> >>Ok, I rerun the tests with correct flags now: >>cflags base: -O3 -fomit-frame-pointer -march=athlon -funroll-loops -fstrict-aliasing -malign-double >>cflags peak: -O3 -fomit-frame-pointer -march=athlon -funroll-loops -fstrict-aliasing -malign-double >> >>Sorry - and thanks for looking closer into these... >> > Ok :-) > > Any chance you can run also SPECfp2000 (at least 200.sixtrack) ??? No problem, I'll run everything. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-06 1:43 ` Paolo Carlini 2002-02-06 1:43 ` Andreas Jaeger @ 2002-02-06 1:50 ` Andreas Jaeger 1 sibling, 0 replies; 41+ messages in thread From: Andreas Jaeger @ 2002-02-06 1:50 UTC (permalink / raw) To: Paolo Carlini; +Cc: gcc Paolo, I'll send you the results automatically when they're finished (I use a script that mails the output ;-) - and send both of them tomorrow to the mailing list manually. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-06 0:59 ` Andreas Jaeger 2002-02-06 1:05 ` Paolo Carlini @ 2002-02-06 13:08 ` Andreas Jaeger 2002-02-06 14:09 ` Laurent Guerby 1 sibling, 1 reply; 41+ messages in thread From: Andreas Jaeger @ 2002-02-06 13:08 UTC (permalink / raw) To: Paolo Carlini; +Cc: gcc, rth [-- Attachment #1: Type: text/plain, Size: 384 bytes --] I hope these results are fine now - the differences are minimal, Andreas Base Compiler: GCC CVS as of Feb 5 2002 8am UTC Peak Compiler: base plus reversion of loop unrolling patch cflags base: -O3 -fomit-frame-pointer -march=athlon -funroll-loops -fstrict-aliasing -malign-double cflags peak: -O3 -fomit-frame-pointer -march=athlon -funroll-loops -fstrict-aliasing -malign-double [-- Attachment #2: CINT2000.012.asc --] [-- Type: text/plain, Size: 7257 bytes --] ############################################################################## # INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN # # # # 'reportable' flag not set during run # # # # INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN # ############################################################################## SPEC CINT2000 Summary Unknown Unknown Tested by SuSE GmbH Wed Feb 6 10:42:56 2002 SPEC License #1922 Test date: 2002-02-06 Hardware availability: June 2001 Tester: Andreas Jaeger, SuSE GmbH Software availability: Now Estimated Estimated Base Base Base Peak Peak Peak Benchmarks Ref Time Run Time Ratio Ref Time Run Time Ratio ------------ -------- -------- -------- -------- -------- -------- 164.gzip 1400 303 462 1400 304 460 164.gzip 1400 303 461* 1400 301 466* 164.gzip 1400 304 461 1400 301 466 175.vpr 1400 541 259 1400 541 259* 175.vpr 1400 541 259* 1400 541 259 175.vpr 1400 541 259 1400 543 258 176.gcc 1100 343 320 1100 343 320 176.gcc 1100 341 323* 1100 342 322* 176.gcc 1100 339 324 1100 341 323 181.mcf 1800 1001 180 1800 1003 179 181.mcf 1800 1001 180* 1800 1001 180 181.mcf 1800 999 180 1800 1003 179* 186.crafty 1000 191 524* 1000 191 524 186.crafty 1000 191 524 1000 191 525* 186.crafty 1000 191 525 1000 191 525 197.parser 1800 554 325* 1800 554 325 197.parser 1800 554 325 1800 554 325 197.parser 1800 554 325 1800 554 325* 252.eon 1300 203 642* 1300 203 640 252.eon 1300 203 641 1300 203 642 252.eon 1300 202 642 1300 203 641* 253.perlbmk 1800 364 494 1800 364 494 253.perlbmk 1800 364 495* 1800 364 495 253.perlbmk 1800 364 495 1800 364 495* 254.gap 1100 302 365 1100 303 363 254.gap 1100 301 366* 1100 300 366* 254.gap 1100 301 366 1100 300 366 255.vortex 1900 464 410* 1900 465 409 255.vortex 1900 464 410 1900 463 411 255.vortex 1900 464 409 1900 463 410* 256.bzip2 1500 493 304 1500 493 304 256.bzip2 1500 492 305 1500 492 305* 256.bzip2 1500 492 305* 1500 492 305 300.twolf 3000 1056 284* 3000 1060 283 300.twolf 3000 1058 284 3000 1060 283* 300.twolf 3000 1056 284 3000 1057 284 ======================================================================== 164.gzip 1400 303 461* 1400 301 466* 175.vpr 1400 541 259* 1400 541 259* 176.gcc 1100 341 323* 1100 342 322* 181.mcf 1800 1001 180* 1800 1003 179* 186.crafty 1000 191 524* 1000 191 525* 197.parser 1800 554 325* 1800 554 325* 252.eon 1300 203 642* 1300 203 641* 253.perlbmk 1800 364 495* 1800 364 495* 254.gap 1100 301 366* 1100 300 366* 255.vortex 1900 464 410* 1900 463 410* 256.bzip2 1500 492 305* 1500 492 305* 300.twolf 3000 1056 284* 3000 1060 283* Est. SPECint_base2000 361 Est. SPECint2000 361 HARDWARE -------- Hardware Vendor: Unknown Model Name: Unknown CPU: AMD Athlon(tm) Processor CPU MHz: 1102.541 FPU: Integrated CPU(s) enabled: 1 CPU(s) orderable: 1 Parallel: No Primary Cache: Secondary Cache: 256 KB L3 Cache: N/A Other Cache: N/A Memory: 496 MB Disk Subsystem: Unknown Other Hardware: Ethernet SOFTWARE -------- Operating System: SuSE Linux 7.3 (i386) Compiler: GCC CVS File System: Linux/ReiserFS System State: Multi-User NOTES ----- Base flags: -O3 -fomit-frame-pointer -march=athlon -funroll-loops -fstrict-aliasing -malign-double GCC CVS as of Feb 5 2002 8am UTC Peak flags: -O3 -fomit-frame-pointer -march=athlon -funroll-loops -fstrict-aliasing -malign-double base plus reversion of loop unrolling patch To compile and execute eon correctly the following extra flags are used for compilation: -ffast-math -fwritable-strings. ############################################################################## # INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN # # # # 'reportable' flag not set during run # # # # INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN # ############################################################################## ----------------------------------------------------------------------------- For questions about this result, please contact the tester. For other inquiries, please contact webmaster@spec.org. Copyright 1999-2000 Standard Performance Evaluation Corporation Generated on Wed Feb 6 20:47:55 2002 by SPEC CPU2000 ASCII formatter v2.1 [-- Attachment #3: Type: text/plain, Size: 100 bytes --] -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-06 13:08 ` Andreas Jaeger @ 2002-02-06 14:09 ` Laurent Guerby 2002-02-06 14:45 ` Dale Johannesen 2002-02-06 15:00 ` Andreas Jaeger 0 siblings, 2 replies; 41+ messages in thread From: Laurent Guerby @ 2002-02-06 14:09 UTC (permalink / raw) To: Andreas Jaeger; +Cc: Paolo Carlini, gcc, rth I just merged your base results with: <http://www.spec.org/osg/cpu2000/results/res2000q4/cpu2000-20001204-00426.asc> GCC S G/S SP G/SP 164.gzip 461 472 0.976 563 0.818 175.vpr 259 255 1.015 285 0.908 176.gcc 323 248 1.302 355 0.909 181.mcf 180 194 0.927 196 0.918 186.crafty 524 632 0.829 678 0.772 197.parser 325 372 0.873 373 0.871 252.eon 642 692 0.927 1056 0.607 253.perlbmk 495 668 0.741 720 0.687 254.gap 366 441 0.829 441 0.829 255.vortex 410 702 0.584 731 0.560 256.bzip2 305 335 0.910 343 0.889 300.twolf 284 340 0.835 360 0.788 GCC = GCC base, S = SPEC base, SP = SPEC peak This was with the closest SPEC run I found, however the MHz are different, so I don't know if a rescale is needed: SPEC web: CPU: 1.2GHz AMD Athlon processor A1200AMT3B Andreas : CPU MHz: 1102.541 Apparent weaknesses on base are vortex and perlbmk, has anyone looked at them? perl might be interesting, 25% base performance hit on such a complex piece of free software, there must be some critical interpreter piece of code completely miscompiled by CVS GCC (performance-wise). Any perl hacker willing to zoom on it? Does anyone know if it is a performance regression from previous GCC? I assume eon and vortex are easy targets for "one optimisation gets all" and might be less interesting to look at. -- Laurent Guerby <guerby@acm.org> ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-06 14:09 ` Laurent Guerby @ 2002-02-06 14:45 ` Dale Johannesen 2002-02-06 15:08 ` Andreas Jaeger 2002-02-07 3:48 ` Jan Hubicka 2002-02-06 15:00 ` Andreas Jaeger 1 sibling, 2 replies; 41+ messages in thread From: Dale Johannesen @ 2002-02-06 14:45 UTC (permalink / raw) To: Laurent Guerby; +Cc: Dale Johannesen, Andreas Jaeger, Paolo Carlini, gcc, rth On Wednesday, February 6, 2002, at 02:08 PM, Laurent Guerby wrote: > GCC S G/S SP G/SP > 164.gzip 461 472 0.976 563 0.818 > 175.vpr 259 255 1.015 285 0.908 > 176.gcc 323 248 1.302 355 0.909 > 181.mcf 180 194 0.927 196 0.918 > 186.crafty 524 632 0.829 678 0.772 > 197.parser 325 372 0.873 373 0.871 > 252.eon 642 692 0.927 1056 0.607 > 253.perlbmk 495 668 0.741 720 0.687 > 254.gap 366 441 0.829 441 0.829 > 255.vortex 410 702 0.584 731 0.560 > 256.bzip2 305 335 0.910 343 0.889 > 300.twolf 284 340 0.835 360 0.788 > > Apparent weaknesses on base are vortex and perlbmk, has > anyone looked at them? perl might be interesting, 25% > base performance hit on such a complex piece of free software, > there must be some critical interpreter piece of code > completely miscompiled by CVS GCC (performance-wise). I looked at Spec quite a bit for my last job and I can suggest some things that are important. Intelligent use of profiling info from the first pass is important. You'll see the published numbers do this. Last time I looked gcc used this only for branch straightening; it can also be used effectively to drive inlining and register allocation. crafty is heavily dependent on efficiency of "long long". It's a chess program, full of 64-bit bitmasks. eon is the only one in C++. If there are any problems in exception handling they will show up here. The program does not actually throw any exceptions, so turning off the handling for peak may help (SPEC won't let you turn it off for base). Good inlining decisions are also important. the two most heavily executed functions in perl are big; IME register allocation & scheduling don't always work well for big functions. They also both call setjmp; if this disables any substantial amount of optimization it will hurt. vortex accesses a huge amount of virtual memory. Good malloc/free performance is critical. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-06 14:45 ` Dale Johannesen @ 2002-02-06 15:08 ` Andreas Jaeger 2002-02-07 3:59 ` Jan Hubicka 2002-02-07 7:27 ` Michael Matz 2002-02-07 3:48 ` Jan Hubicka 1 sibling, 2 replies; 41+ messages in thread From: Andreas Jaeger @ 2002-02-06 15:08 UTC (permalink / raw) To: Dale Johannesen; +Cc: Laurent Guerby, Paolo Carlini, gcc, rth Dale Johannesen <dalej@apple.com> writes: > Intelligent use of profiling info from the first pass is > important. You'll see the published numbers do this. > Last time I looked gcc used this only for branch > straightening; it can also be used effectively to > drive inlining and register allocation. AFAIK the infrastructure is there, it only needs to be used for inlining - and also in the new register allocator. Michal, is this possible? > crafty is heavily dependent on efficiency of "long long". > It's a chess program, full of 64-bit bitmasks. > > eon is the only one in C++. If there are any problems > in exception handling they will show up here. The program > does not actually throw any exceptions, so turning off > the handling for peak may help (SPEC won't let you turn > it off for base). Good inlining decisions are also important. The inline change brought in August by Kurt Garloff brought a real performance improvement, check my graphs at http://www.suse.de/~aj/SPEC > the two most heavily executed functions in perl are big; > IME register allocation & scheduling don't always work > well for big functions. They also both call setjmp; if > this disables any substantial amount of optimization it > will hurt. > > vortex accesses a huge amount of virtual memory. Good > malloc/free performance is critical. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-06 15:08 ` Andreas Jaeger @ 2002-02-07 3:59 ` Jan Hubicka 2002-02-07 7:27 ` Michael Matz 1 sibling, 0 replies; 41+ messages in thread From: Jan Hubicka @ 2002-02-07 3:59 UTC (permalink / raw) To: Andreas Jaeger; +Cc: Dale Johannesen, Laurent Guerby, Paolo Carlini, gcc, rth > Dale Johannesen <dalej@apple.com> writes: > > > Intelligent use of profiling info from the first pass is > > important. You'll see the published numbers do this. > > Last time I looked gcc used this only for branch > > straightening; it can also be used effectively to > > drive inlining and register allocation. > > AFAIK the infrastructure is there, it only needs to be used for > inlining - and also in the new register allocator. Michal, is this > possible? It is not possible to use it for inlining yet, as our loop optimization pass kill profile info, so unless we want to have multiple passes needed for optimization, we need to rewrite that one as well as RTL code generation first. We are working on that. It is already used for register allocation in the mainline as well as for few of other decision. CFG branch is more aggressive already deriving about 5% benefit. I hope this to improve as the code matures. Honza ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-06 15:08 ` Andreas Jaeger 2002-02-07 3:59 ` Jan Hubicka @ 2002-02-07 7:27 ` Michael Matz 1 sibling, 0 replies; 41+ messages in thread From: Michael Matz @ 2002-02-07 7:27 UTC (permalink / raw) To: Andreas Jaeger; +Cc: Dale Johannesen, Laurent Guerby, Paolo Carlini, gcc, rth Hi, On Thu, 7 Feb 2002, Andreas Jaeger wrote: > > Intelligent use of profiling info from the first pass is > > important. You'll see the published numbers do this. > > Last time I looked gcc used this only for branch > > straightening; it can also be used effectively to > > drive inlining and register allocation. > > AFAIK the infrastructure is there, it only needs to be used for > inlining - and also in the new register allocator. Michal, is this > possible? In fact if the numbers I base decisions in the allocator on, are itself based on profiling, then the allocator can already be profile-guided. Basically what I need is only cost estimations for basic blocks (i.e. how often they are run compared to the other blocks in the function). I don't care if they are estimated statically from loop structure or precisely from profiling. Ciao, Michael. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-06 14:45 ` Dale Johannesen 2002-02-06 15:08 ` Andreas Jaeger @ 2002-02-07 3:48 ` Jan Hubicka 2002-02-07 9:42 ` Richard Henderson 1 sibling, 1 reply; 41+ messages in thread From: Jan Hubicka @ 2002-02-07 3:48 UTC (permalink / raw) To: Dale Johannesen; +Cc: Laurent Guerby, Andreas Jaeger, Paolo Carlini, gcc, rth > I looked at Spec quite a bit for my last job and I can > suggest some things that are important. > > Intelligent use of profiling info from the first pass is > important. You'll see the published numbers do this. > Last time I looked gcc used this only for branch > straightening; it can also be used effectively to > drive inlining and register allocation. I did quite active development on this. In 3.1 gcc can do some of optimizations based on profile info, like register allocation. On the cfg-branch we are still focusing on this path for 3.2 timeframe. > > crafty is heavily dependent on efficiency of "long long". > It's a chess program, full of 64-bit bitmasks. This is actually big problem for gcc. It may be workaroundable by using SSE/MMX arithmetics when available. > > eon is the only one in C++. If there are any problems > in exception handling they will show up here. The program > does not actually throw any exceptions, so turning off > the handling for peak may help (SPEC won't let you turn > it off for base). Good inlining decisions are also important. Yes, eon basically appears to be very huge, so everything that shrinks the footprint is usefull. > > the two most heavily executed functions in perl are big; > IME register allocation & scheduling don't always work > well for big functions. They also both call setjmp; if > this disables any substantial amount of optimization it > will hurt. Our setjmp handling should be aggressive enought. We represent it as abnormal edge in the CFG and this optimize the rest of function w/o much of degradation. Honza ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-07 3:48 ` Jan Hubicka @ 2002-02-07 9:42 ` Richard Henderson 0 siblings, 0 replies; 41+ messages in thread From: Richard Henderson @ 2002-02-07 9:42 UTC (permalink / raw) To: Jan Hubicka Cc: Dale Johannesen, Laurent Guerby, Andreas Jaeger, Paolo Carlini, gcc On Thu, Feb 07, 2002 at 12:46:45PM +0100, Jan Hubicka wrote: > Our setjmp handling should be aggressive enought. We represent > it as abnormal edge in the CFG and this optimize the rest of > function w/o much of degradation. No we don't. We _talked_ about doing that. r~ ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-06 14:09 ` Laurent Guerby 2002-02-06 14:45 ` Dale Johannesen @ 2002-02-06 15:00 ` Andreas Jaeger 2002-02-07 5:22 ` Laurent Guerby 1 sibling, 1 reply; 41+ messages in thread From: Andreas Jaeger @ 2002-02-06 15:00 UTC (permalink / raw) To: Laurent Guerby; +Cc: Paolo Carlini, gcc, rth Laurent Guerby <guerby@acm.org> writes: > I just merged your base results with: > > <http://www.spec.org/osg/cpu2000/results/res2000q4/cpu2000-20001204-00426.asc> > > GCC S G/S SP G/SP > 164.gzip 461 472 0.976 563 0.818 > 175.vpr 259 255 1.015 285 0.908 > 176.gcc 323 248 1.302 355 0.909 > 181.mcf 180 194 0.927 196 0.918 > 186.crafty 524 632 0.829 678 0.772 > 197.parser 325 372 0.873 373 0.871 > 252.eon 642 692 0.927 1056 0.607 > 253.perlbmk 495 668 0.741 720 0.687 > 254.gap 366 441 0.829 441 0.829 > 255.vortex 410 702 0.584 731 0.560 > 256.bzip2 305 335 0.910 343 0.889 > 300.twolf 284 340 0.835 360 0.788 > > GCC = GCC base, S = SPEC base, SP = SPEC peak > > This was with the closest SPEC run I found, however > the MHz are different, so I don't know if a rescale is needed: > > SPEC web: CPU: 1.2GHz AMD Athlon processor A1200AMT3B > Andreas : CPU MHz: 1102.541 A rescale is needed. Better take these values that I measured under Linux with the same CPU as in http://www.spec.org/osg/cpu2000/results/res2001q2/cpu2000-20010519-00651.asc (use those values for comparison!): Compiler GCC 3.1 from CVS of 2001-11-07 Base flags: -O3 -march=athlon -fomit-frame-pointer Peak flags: -O3 -march=athlon -fomit-frame-pointer, FDO: Pass1: -fprofile-arcs, Pass2 -fbranch-probabilities Estimated Estimated Base Base Base Peak Peak Peak Benchmarks Ref Time Run Time Ratio Ref Time Run Time Ratio 164.gzip 1400 274 511 1400 264 530 175.vpr 1400 451 310 1400 464 302 176.gcc 1100 286 384 1100 275 400 181.mcf 1800 829 217 1800 897 201 186.crafty 1000 171 585 1000 163 614 197.parser 1800 470 383 1800 465 387 252.eon 1300 211 616 1300 210 618 253.perlbmk 1800 321 562 1800 309 583 254.gap 1100 235 467 1100 228 482 255.vortex 1900 401 474 1900 379 501 256.bzip2 1500 378 397 1500 398 377 300.twolf 3000 908 331 3000 892 336 SPECint_base2000 420 SPECint2000 424 Hardware: Dual AMD Athlon 1.2 GHz, 1 GB Memory, SCSI system Software: SuSE Linux 7.3. > Apparent weaknesses on base are vortex and perlbmk, has > anyone looked at them? perl might be interesting, 25% > base performance hit on such a complex piece of free software, > there must be some critical interpreter piece of code > completely miscompiled by CVS GCC (performance-wise). > > Any perl hacker willing to zoom on it? > Does anyone know if it is a performance regression from previous GCC? > > I assume eon and vortex are easy targets for "one > optimisation gets all" and might be less interesting > to look at. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-06 15:00 ` Andreas Jaeger @ 2002-02-07 5:22 ` Laurent Guerby 2002-02-07 5:46 ` Cannot allocate 92625564 bytes after allocating 198356992 bytes Dimitri Frederickx [not found] ` <ho8za5ijlt.fsf@gee.suse.de> 0 siblings, 2 replies; 41+ messages in thread From: Laurent Guerby @ 2002-02-07 5:22 UTC (permalink / raw) To: Andreas Jaeger; +Cc: Paolo Carlini, gcc, rth Here is the new comparison between AMD (S): http://www.spec.org/osg/cpu2000/results/res2000q4/cpu2000-20001204-00426.asc Andreas (G): http://www.spec.org/osg/cpu2000/results/res2001q2/cpu2000-20010519-00651.asc G S G/S GP SP GP/SP 164.gzip 608 472 1.288 619 563 1.099 175.vpr 319 255 1.250 342 285 1.200 176.gcc 357 248 1.439 430 355 1.211 181.mcf 229 194 1.180 232 196 1.183 186.crafty 665 632 1.052 692 678 1.020 197.parser 436 372 1.172 434 373 1.163 252.eon 839 692 1.212 1046 1056 0.990 253.perlbmk 759 668 1.136 748 720 1.038 254.gap 581 441 1.317 579 441 1.312 255.vortex 764 702 1.088 796 731 1.088 256.bzip2 401 335 1.197 423 343 1.233 300.twolf 417 340 1.226 421 360 1.169 I assume I have made a stoopid mistake somewhere, otherwise why is AMD still submitting SPEC results based on the Intel compiler? May be SPECfp is showing another picture though. -- Laurent Guerby <guerby@acm.org> ^ permalink raw reply [flat|nested] 41+ messages in thread
* Cannot allocate 92625564 bytes after allocating 198356992 bytes 2002-02-07 5:22 ` Laurent Guerby @ 2002-02-07 5:46 ` Dimitri Frederickx [not found] ` <ho8za5ijlt.fsf@gee.suse.de> 1 sibling, 0 replies; 41+ messages in thread From: Dimitri Frederickx @ 2002-02-07 5:46 UTC (permalink / raw) To: gcc-help, gcc While compiling my sourcecode with gcc I get the following message: (I use jam to compile my sources) Cc /home/Administrator/open-wonka/build-x86-winnt/wonka/bin/unicode.o cc1.exe: Cannot allocate 92625564 bytes after allocating 198356992 bytes gcc -c -Wall -Wsign-compare -Wshadow -Wpointer-arith -Wstrict-prototypes -W inline -Wconversion -DDEBUG_LEVEL=7 -DVERSION_STRING='"WONKA-0-8-RELEASE"' - D__NO_STRING_INLINES -DWINNT -DBOOTCLASSDIR='"boot"' -DBOOTCLASSFILE='"class es.zip"' -DDEBUG -DRUNTIME_CHECKS -ggdb -DFICL -DENABLE_GC -DDISABLE_PS -DOS WALD -DFSROOT='"./fsroot"' -fno-leading-underscore -O2 -I/home/Administrat or/open-wonka/wonka/src/vm -I/home/Administrator/open-wonka/kernel/oswald/in clude -I/home/Administrator/open-wonka/kernel/oswald/hal/host/winnt/include -I/home/Administrator/open-wonka/kernel/oswald/hal/cpu/x86/include -I/home/A dministrator/open-wonka/wonka/include -I/home/Administrator/open-wonka/wonka /hal/cpu/x86/include -I/home/Administrator/open-wonka/wonka/hal/hostos/winnt /include -I/home/Administrator/open-wonka/network/none/include -I/home/Admin istrator/open-wonka/wonka/include -I/home/Administrator/open-wonka/wonka/hal /cpu/x86/include -I/home/Administrator/open-wonka/wonka/hal/hostos/winnt/inc lude -I/home/Administrator/open-wonka/build-x86-winnt/wonka/bin -I/home/Admi nistrator/open-wonka/build-x86-winnt/awt/none/bin -I/home/Administrator/open -wonka/fs/native/hal/hostos/winnt/include -I/home/Administrator/open-wonka/f s/native/include -I/home/Administrator/open-wonka/jpda/jdwp/include -o /home/Administrator/open-wonka/build-x86-winnt/wonka/bin/unicode.o /home/Administrator/open-wonka/build-x86-winnt/wonka/bin/unicode.c ...failed Cc /home/Administrator/open-wonka/build-x86-winnt/wonka/bin/unicode.o ... What does this message mean? Why do I get it? Why can't I compile my source? How do I solve it? Dimitri Frederickx Student Industrial Engineer ^ permalink raw reply [flat|nested] 41+ messages in thread
[parent not found: <ho8za5ijlt.fsf@gee.suse.de>]
* Re: Loop unrolling-related SPEC regressions? [not found] ` <ho8za5ijlt.fsf@gee.suse.de> @ 2002-02-07 11:52 ` Laurent Guerby 0 siblings, 0 replies; 41+ messages in thread From: Laurent Guerby @ 2002-02-07 11:52 UTC (permalink / raw) To: Andreas Jaeger, gcc Andreas Jaeger wrote: > ??? Both pages uses Intel's compiler. You just compared two windows > results - or am I missing something? I misinterpreted the URL you gave as being your results, indeed my first comparison was just showing off the yearly progress of the Intel compiler dudes on generating better AMD Athlon code, quite impressive :). > What is interesting is the comparance of my GCC values together with > AMD's values from 2001q2, G: http://gcc.gnu.org/ml/gcc/2002-02/msg00448.html A: http://www.spec.org/osg/cpu2000/results/res2001q2/cpu2000-20010519-00651.asc G A G/A GP AP GP/AP 164.gzip 511 608 0.840 530 619 0.856 175.vpr 310 319 0.971 302 342 0.883 176.gcc 384 357 1.075 400 430 0.930 181.mcf 217 229 0.947 201 232 0.866 (1) 186.crafty 585 665 0.879 614 692 0.887 197.parser 383 436 0.878 387 434 0.891 (2) 252.eon 616 839 0.734 618 1046 0.590 253.perlbmk 562 759 0.740 583 748 0.779 (2) 254.gap 467 581 0.803 482 579 0.832 (2) 255.vortex 474 764 0.620 501 796 0.629 256.bzip2 397 401 0.990 377 423 0.891 (1) 300.twolf 331 417 0.793 336 421 0.798 (1) GCC peak < GCC base, profile feedback not working as intended :). (2) AMD peak < AMD base (???) Still 20-something % on perl. -- Laurent Guerby <guerby@acm.org> ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-01 10:32 Loop unrolling-related SPEC regressions? Paolo Carlini 2002-02-01 10:46 ` Richard Henderson @ 2002-02-01 11:14 ` Joe Buck 2002-02-04 8:45 ` Andreas Jaeger 2002-02-04 10:58 ` Jan Hubicka 1 sibling, 2 replies; 41+ messages in thread From: Joe Buck @ 2002-02-01 11:14 UTC (permalink / raw) To: Paolo Carlini; +Cc: gcc, rth > browsing the latest results from Andreas, it looks like a few of them (e.g., > 164.gzip, 186.crafty, 200.sixtrack) are showing a definite regression in the > PEAK case, characterized by -funroll-all-loops. It's not clear to me that -funroll-all-loops is the correct setting for PEAK, as bloating out the code may make the cache perform worse. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-01 11:14 ` Joe Buck @ 2002-02-04 8:45 ` Andreas Jaeger 2002-02-04 10:58 ` Jan Hubicka 1 sibling, 0 replies; 41+ messages in thread From: Andreas Jaeger @ 2002-02-04 8:45 UTC (permalink / raw) To: Joe Buck; +Cc: Paolo Carlini, gcc, rth Joe Buck <jbuck@synopsys.COM> writes: >> browsing the latest results from Andreas, it looks like a few of them (e.g., >> 164.gzip, 186.crafty, 200.sixtrack) are showing a definite regression in the >> PEAK case, characterized by -funroll-all-loops. > > It's not clear to me that -funroll-all-loops is the correct setting for > PEAK, as bloating out the code may make the cache perform worse. I know it's not the best setting but I'm not going for the best numbers but for consistency - and like to test different areas of the compiler. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-01 11:14 ` Joe Buck 2002-02-04 8:45 ` Andreas Jaeger @ 2002-02-04 10:58 ` Jan Hubicka 2002-02-04 11:07 ` Paolo Carlini 2002-02-04 11:20 ` Joe Buck 1 sibling, 2 replies; 41+ messages in thread From: Jan Hubicka @ 2002-02-04 10:58 UTC (permalink / raw) To: Joe Buck; +Cc: Paolo Carlini, gcc, rth > > > browsing the latest results from Andreas, it looks like a few of them (e.g., > > 164.gzip, 186.crafty, 200.sixtrack) are showing a definite regression in the > > PEAK case, characterized by -funroll-all-loops. > > It's not clear to me that -funroll-all-loops is the correct setting for > PEAK, as bloating out the code may make the cache perform worse. We do use them in the testing runs for exactly these purposes. It tends to show the "bugs" that causes unnecesary code growth in some areas unnoticed by other benchmarks. THe base/peak flags are not supposed to bring best performance, but be good for testing majority of gcc features. Honza ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-04 10:58 ` Jan Hubicka @ 2002-02-04 11:07 ` Paolo Carlini 2002-02-04 12:12 ` Andreas Jaeger 2002-02-04 11:20 ` Joe Buck 1 sibling, 1 reply; 41+ messages in thread From: Paolo Carlini @ 2002-02-04 11:07 UTC (permalink / raw) To: Jan Hubicka; +Cc: gcc Jan Hubicka wrote: > > > > > browsing the latest results from Andreas, it looks like a few of them (e.g., > > > 164.gzip, 186.crafty, 200.sixtrack) are showing a definite regression in the > > > PEAK case, characterized by -funroll-all-loops. > > > > It's not clear to me that -funroll-all-loops is the correct setting for > > PEAK, as bloating out the code may make the cache perform worse. > > We do use them in the testing runs for exactly these purposes. > It tends to show the "bugs" that causes unnecesary code growth in some > areas unnoticed by other benchmarks. > THe base/peak flags are not supposed to bring best performance, > but be good for testing majority of gcc features. That's really enlightening Honza! Thanks for the clarification. We should also remember this when someone compares the SPEC numbers made available by other compiler producers with those of GCC: my guess is that this kind of rationale for choosing the PEAK flags it's unfortunately not so widespread... Cheers, Paolo. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-04 11:07 ` Paolo Carlini @ 2002-02-04 12:12 ` Andreas Jaeger 2002-02-04 16:36 ` Paolo Carlini 2002-02-04 21:34 ` Tim Prince 0 siblings, 2 replies; 41+ messages in thread From: Andreas Jaeger @ 2002-02-04 12:12 UTC (permalink / raw) To: Paolo Carlini; +Cc: Jan Hubicka, gcc Paolo Carlini <pcarlini@unitus.it> writes: > Jan Hubicka wrote: > >> > >> > > browsing the latest results from Andreas, it looks like a few of them (e.g., >> > > 164.gzip, 186.crafty, 200.sixtrack) are showing a definite regression in the >> > > PEAK case, characterized by -funroll-all-loops. >> > >> > It's not clear to me that -funroll-all-loops is the correct setting for >> > PEAK, as bloating out the code may make the cache perform worse. >> >> We do use them in the testing runs for exactly these purposes. >> It tends to show the "bugs" that causes unnecesary code growth in some >> areas unnoticed by other benchmarks. >> THe base/peak flags are not supposed to bring best performance, >> but be good for testing majority of gcc features. > > That's really enlightening Honza! Thanks for the clarification. > We should also remember this when someone compares the SPEC numbers made available > by other compiler producers with those of GCC: my guess is that this kind of > rationale for choosing the PEAK flags it's unfortunately not so widespread... Didn't I mention it that way? Feel free to send a patch for my SPEC page to clarify what we're doing... thanks, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-04 12:12 ` Andreas Jaeger @ 2002-02-04 16:36 ` Paolo Carlini 2002-02-04 21:34 ` Tim Prince 1 sibling, 0 replies; 41+ messages in thread From: Paolo Carlini @ 2002-02-04 16:36 UTC (permalink / raw) To: Andreas Jaeger; +Cc: gcc Andreas Jaeger wrote: > > That's really enlightening Honza! Thanks for the clarification. > > We should also remember this when someone compares the SPEC numbers made available > > by other compiler producers with those of GCC: my guess is that this kind of > > rationale for choosing the PEAK flags it's unfortunately not so widespread... > > Didn't I mention it that way? Feel free to send a patch for my SPEC > page to clarify what we're doing... No, your pages indeed present the tests exactly in this way. It's my fault not having read the descriptive text attentively before. Anyway, I look forward to see your numbers relative to the PEAK-type flags (but -funroll-loops) with/without RTH unroller fix. Thanks, Paolo. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-04 12:12 ` Andreas Jaeger 2002-02-04 16:36 ` Paolo Carlini @ 2002-02-04 21:34 ` Tim Prince 2002-02-05 4:32 ` Jan Hubicka 1 sibling, 1 reply; 41+ messages in thread From: Tim Prince @ 2002-02-04 21:34 UTC (permalink / raw) To: Andreas Jaeger, Paolo Carlini; +Cc: Jan Hubicka, gcc On Monday 04 February 2002 11:48, Andreas Jaeger wrote: > Paolo Carlini <pcarlini@unitus.it> writes: > > Jan Hubicka wrote: > > >> THe base/peak flags are not supposed to bring best performance, > >> but be good for testing majority of gcc features. > > > > That's really enlightening Honza! Thanks for the clarification. > > We should also remember this when someone compares the SPEC numbers made > > available by other compiler producers with those of GCC: my guess is that > > this kind of rationale for choosing the PEAK flags it's unfortunately not > > so widespread... > > Didn't I mention it that way? Feel free to send a patch for my SPEC > page to clarify what we're doing... Of course, compilers which are sold on the basis of SPEC base performance have different approach to default options than gcc. One expects the base option set to be the one which is the best single setting conforming to the limit on number of options, to obtain the highest rating. Thus, a compiler such as Intel's makes a simple option package such as 'icc -xW -Oi-' roughly equivalent to 'gcc -msse2 -march=pentium4 -Os -funroll-loops -mpreferred-stack-boundary=4 -ffast-math' with even the base rating depending on Profile Guided Optimization. Of course, one expects the peak rating to be found with a set of options which produces the fastest acceptable result for each test, not necessarily the most aggressive group of optimizations. In that light, the SPEC disclosures allow one to speculate as to how much trial and error work was needed to obtain the results submitted, and how much more might be needed to achieve equivalent performance on a typical application. I thank Andreas and Honza for explaining the difference between what they have done and what some of us may have expected. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-04 21:34 ` Tim Prince @ 2002-02-05 4:32 ` Jan Hubicka 2002-02-05 14:05 ` Geoff Keating 2002-02-05 20:57 ` Tim Prince 0 siblings, 2 replies; 41+ messages in thread From: Jan Hubicka @ 2002-02-05 4:32 UTC (permalink / raw) To: Tim Prince; +Cc: Andreas Jaeger, Paolo Carlini, Jan Hubicka, gcc > On Monday 04 February 2002 11:48, Andreas Jaeger wrote: > > Paolo Carlini <pcarlini@unitus.it> writes: > > > Jan Hubicka wrote: > > > > >> THe base/peak flags are not supposed to bring best performance, > > >> but be good for testing majority of gcc features. > > > > > > That's really enlightening Honza! Thanks for the clarification. > > > We should also remember this when someone compares the SPEC numbers made > > > available by other compiler producers with those of GCC: my guess is that > > > this kind of rationale for choosing the PEAK flags it's unfortunately not > > > so widespread... > > > > Didn't I mention it that way? Feel free to send a patch for my SPEC > > page to clarify what we're doing... > Of course, compilers which are sold on the basis of SPEC base performance > have different approach to default options than gcc. One expects the > base option set to be the one which is the best single setting conforming to > the limit on number of options, to obtain the highest rating. Thus, a > compiler such as Intel's makes a simple option package such as > 'icc -xW -Oi-' > roughly equivalent to > 'gcc -msse2 -march=pentium4 -Os -funroll-loops -mpreferred-stack-boundary=4 > -ffast-math' I am playing with the idea of making -O behaving like -f and allowing -Ospeed "optimize for maximal speed for common circmuatens" and -Osize. We can also invent -O[no]debug "prohibit optimizations that make debugging dificult, like tail call optimization, frame pointer ellimination, or (currently) register renaming", or -Odangerous "enable language standard breaking transformations". Perhaps that can be usefull not only to "fit in" the spec2000 rules, but also to avoid confusion of users. Many benchmarks published uses far from "sane" compilation switches. Honza > with even the base rating depending on Profile Guided Optimization. > Of course, one expects the peak rating to be found with a set of options > which produces the fastest acceptable result for each test, not necessarily > the most aggressive group of optimizations. In that light, the SPEC > disclosures allow one to speculate as to how much trial and error work was > needed to obtain the results submitted, and how much more might be needed to > achieve equivalent performance on a typical application. > > I thank Andreas and Honza for explaining the difference between what they > have done and what some of us may have expected. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-05 4:32 ` Jan Hubicka @ 2002-02-05 14:05 ` Geoff Keating 2002-02-06 3:32 ` Jan Hubicka 2002-02-05 20:57 ` Tim Prince 1 sibling, 1 reply; 41+ messages in thread From: Geoff Keating @ 2002-02-05 14:05 UTC (permalink / raw) To: Jan Hubicka; +Cc: gcc Jan Hubicka <jh@suse.cz> writes: > I am playing with the idea of making -O behaving like -f and allowing -Ospeed > "optimize for maximal speed for common circmuatens" and -Osize. We can also > invent -O[no]debug "prohibit optimizations that make debugging dificult, like > tail call optimization, frame pointer ellimination, or (currently) register > renaming", Don't we already have these? -O3 is what you call 'Ospeed', -Os is what you call 'Osize', '-O0' is Odebug. -- - Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com> ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-05 14:05 ` Geoff Keating @ 2002-02-06 3:32 ` Jan Hubicka 0 siblings, 0 replies; 41+ messages in thread From: Jan Hubicka @ 2002-02-06 3:32 UTC (permalink / raw) To: Geoff Keating; +Cc: Jan Hubicka, gcc > Jan Hubicka <jh@suse.cz> writes: > > > I am playing with the idea of making -O behaving like -f and allowing -Ospeed > > "optimize for maximal speed for common circmuatens" and -Osize. We can also > > invent -O[no]debug "prohibit optimizations that make debugging dificult, like > > tail call optimization, frame pointer ellimination, or (currently) register > > renaming", > > Don't we already have these? -O3 is what you call 'Ospeed', -Os is > what you call 'Osize', '-O0' is Odebug. Yes and no. Defnitly to get best perofrmance you don't need to enable just -march=mymodel -O3 We disable some options at higher optimizations levels just to allow debugging (like -fomit-frame-pointer, register renaming, loop unrolling). It is somewhat dificult to orientate in the optimization levels for users and I am not sure what exactly can we do with the situation. Honza > > -- > - Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com> ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-05 4:32 ` Jan Hubicka 2002-02-05 14:05 ` Geoff Keating @ 2002-02-05 20:57 ` Tim Prince 1 sibling, 0 replies; 41+ messages in thread From: Tim Prince @ 2002-02-05 20:57 UTC (permalink / raw) To: Jan Hubicka; +Cc: Andreas Jaeger, Paolo Carlini, Jan Hubicka, gcc On Tuesday 05 February 2002 04:29, Jan Hubicka wrote: > > On Monday 04 February 2002 11:48, Andreas Jaeger wrote: > > > Paolo Carlini <pcarlini@unitus.it> writes: > > > > Jan Hubicka wrote: > > > >> THe base/peak flags are not supposed to bring best performance, > > > >> but be good for testing majority of gcc features. > > > > > > > > That's really enlightening Honza! Thanks for the clarification. > > > > We should also remember this when someone compares the SPEC numbers > > > > made available by other compiler producers with those of GCC: my > > > > guess is that this kind of rationale for choosing the PEAK flags it's > > > > unfortunately not so widespread... > > > > > > Didn't I mention it that way? Feel free to send a patch for my SPEC > > > page to clarify what we're doing... > > > > Of course, compilers which are sold on the basis of SPEC base performance > > have different approach to default options than gcc. One expects the > > base option set to be the one which is the best single setting conforming > > to the limit on number of options, to obtain the highest rating. Thus, a > > compiler such as Intel's makes a simple option package such as > > 'icc -xW -Oi-' > > roughly equivalent to > > 'gcc -msse2 -march=pentium4 -Os -funroll-loops > > -mpreferred-stack-boundary=4 -ffast-math' > > I am playing with the idea of making -O behaving like -f and allowing > -Ospeed "optimize for maximal speed for common circmuatens" and -Osize. We > can also invent -O[no]debug "prohibit optimizations that make debugging > dificult, like tail call optimization, frame pointer ellimination, or > (currently) register renaming", or -Odangerous "enable language standard > breaking transformations". I thought that was the meaning of -ffast-math, or do you mean some combination of optimization which includes -ffast-math and -funroll-loops? > > Perhaps that can be usefull not only to "fit in" the spec2000 rules, but > also to avoid confusion of users. Many benchmarks published uses far from > "sane" compilation switches. Yes, there is a need for a simple switch which includes most "sane" optimizations which are useful for a specified architecture, even if it is not quite sufficient for a good SPEC score. > > Honza > > > with even the base rating depending on Profile Guided Optimization. > > Of course, one expects the peak rating to be found with a set of options > > which produces the fastest acceptable result for each test, not > > necessarily the most aggressive group of optimizations. In that light, > > the SPEC disclosures allow one to speculate as to how much trial and > > error work was needed to obtain the results submitted, and how much more > > might be needed to achieve equivalent performance on a typical > > application. > > > > I thank Andreas and Honza for explaining the difference between what they > > have done and what some of us may have expected. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-04 10:58 ` Jan Hubicka 2002-02-04 11:07 ` Paolo Carlini @ 2002-02-04 11:20 ` Joe Buck 2002-02-04 11:33 ` Jan Hubicka 1 sibling, 1 reply; 41+ messages in thread From: Joe Buck @ 2002-02-04 11:20 UTC (permalink / raw) To: Jan Hubicka; +Cc: Joe Buck, Paolo Carlini, gcc, rth Honza writes: > THe base/peak flags are not supposed to bring best performance, > but be good for testing majority of gcc features. gcc's competition, though, tends to use them that way (choosing options that meet the criteria but give best performance). Not that I want to get into a war on that front, but ... ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-04 11:20 ` Joe Buck @ 2002-02-04 11:33 ` Jan Hubicka 2002-02-04 11:47 ` Jan Hubicka 2002-02-05 9:59 ` David Edelsohn 0 siblings, 2 replies; 41+ messages in thread From: Jan Hubicka @ 2002-02-04 11:33 UTC (permalink / raw) To: Joe Buck; +Cc: Jan Hubicka, Paolo Carlini, gcc, rth > Honza writes: > > > THe base/peak flags are not supposed to bring best performance, > > but be good for testing majority of gcc features. > > gcc's competition, though, tends to use them that way (choosing options > that meet the criteria but give best performance). > > Not that I want to get into a war on that front, but ... Hmm, perhaps we can try to make kind of "official" SPEC results when 3.1 release is out. Andreas did some experimentation with the various options (it is linked from the page), and as I remember the loop unrolling -funroll-loops had neutral effect overal, while -funroll-all-loops caused slight performance drop. Thinks may've changed, as I tried to investigate some of the regressions and address some of code size issues. THe code produced by 3.1 should be considerably smaller than code produced by 3.0. Anyway I would like to see the recent regressions solved. Some of them appears to be due to patch: 2001-11-17 Corey Minyard <minyard@acm.org> Richard Henderson <rth@redhat.com> * unroll.c (loop_iterations): Detect one situation in which we overestimate the number of iterations. And: 2001-11-30 Zoltan Hidvegi <hzoli@hzoli.2y.net> * unroll.c (unroll_loop): Correct special exit cases. I tried to investigate these but lacking simple testcase I found it quite dificult. I fixed some defects but still the overall resutls does not improve. FOr 3.2 we hope to have ready new loop unroller code, but for 3.1 this apepars to be important issue. Honza ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-04 11:33 ` Jan Hubicka @ 2002-02-04 11:47 ` Jan Hubicka 2002-02-05 9:59 ` David Edelsohn 1 sibling, 0 replies; 41+ messages in thread From: Jan Hubicka @ 2002-02-04 11:47 UTC (permalink / raw) To: Jan Hubicka; +Cc: Joe Buck, Paolo Carlini, gcc, rth > > Honza writes: > > > > > THe base/peak flags are not supposed to bring best performance, > > > but be good for testing majority of gcc features. > > > > gcc's competition, though, tends to use them that way (choosing options > > that meet the criteria but give best performance). > > > > Not that I want to get into a war on that front, but ... > Hmm, perhaps we can try to make kind of "official" SPEC results when 3.1 release > is out. Andreas did some experimentation with the various options (it is > linked from the page), and as I remember the loop unrolling -funroll-loops > had neutral effect overal, while -funroll-all-loops caused slight performance > drop. Oops, sorry. Looking at the numbers, -funrol-loops/-funroll-all-loops are equivalent in Andreas testing and both slightly (6 seconds) better. For 3.1 I would guess them to be more win because of code size savings around the compiler. Note that for Athlon the optimizer manual recommends heavy inlining and unrolling as the cache sizes are pretty big. This is the case for common benchmarks, even for spec2000 that are often smaller than real world applications. Honza ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Loop unrolling-related SPEC regressions? 2002-02-04 11:33 ` Jan Hubicka 2002-02-04 11:47 ` Jan Hubicka @ 2002-02-05 9:59 ` David Edelsohn 1 sibling, 0 replies; 41+ messages in thread From: David Edelsohn @ 2002-02-05 9:59 UTC (permalink / raw) To: Jan Hubicka; +Cc: Joe Buck, Paolo Carlini, gcc, rth >>>>> Jan Hubicka writes: Jan> Anyway I would like to see the recent regressions solved. Some of them Jan> appears to be due to patch: Jan> 2001-11-17 Corey Minyard <minyard@acm.org> Jan> Richard Henderson <rth@redhat.com> Jan> * unroll.c (loop_iterations): Detect one situation in which we Jan> overestimate the number of iterations. Jan> And: Jan> 2001-11-30 Zoltan Hidvegi <hzoli@hzoli.2y.net> Jan> * unroll.c (unroll_loop): Correct special exit cases. Does this regression also exist on the GCC 3.0 branch? When I tried to integrate Zoli's patch into the GCC trunk, I ran into conflicts with Richard's patch. Richard duplicated some of Zoli's work with a similar patch. Richard's patch to unroll.c is a subset of Zoli's patch. After the problem getting Zoli's original patch reviewed and approved, I decided to wait and see if Richard's subset was enough. Given the hostile reception to Zoli's original patches, it is unfortunate that Richard had to duplicate the work and create nearly identical fixes. I would suggest you investigate whether replacing Richard's partial patch with Zoli's complete version of the patch for unroll.c fixes the problem. Zoli's patch already was approved by Mark Mitchell. Zoli's complete version of the patch is in GCC 3.0 branch. Unless Richard objects, if Zoli's complete patch fixes the problem, we should be able to substitute Zoli's patch for Richard's. David ^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2002-02-07 19:47 UTC | newest] Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-02-01 10:32 Loop unrolling-related SPEC regressions? Paolo Carlini 2002-02-01 10:46 ` Richard Henderson 2002-02-01 10:51 ` Paolo Carlini 2002-02-01 10:57 ` Richard Henderson 2002-02-01 11:12 ` Paolo Carlini 2002-02-04 8:37 ` Andreas Jaeger 2002-02-04 9:05 ` Paolo Carlini 2002-02-04 11:15 ` Andreas Jaeger 2002-02-06 0:59 ` Andreas Jaeger 2002-02-06 1:05 ` Paolo Carlini 2002-02-06 1:39 ` Andreas Jaeger 2002-02-06 1:43 ` Paolo Carlini 2002-02-06 1:43 ` Andreas Jaeger 2002-02-06 1:50 ` Andreas Jaeger 2002-02-06 13:08 ` Andreas Jaeger 2002-02-06 14:09 ` Laurent Guerby 2002-02-06 14:45 ` Dale Johannesen 2002-02-06 15:08 ` Andreas Jaeger 2002-02-07 3:59 ` Jan Hubicka 2002-02-07 7:27 ` Michael Matz 2002-02-07 3:48 ` Jan Hubicka 2002-02-07 9:42 ` Richard Henderson 2002-02-06 15:00 ` Andreas Jaeger 2002-02-07 5:22 ` Laurent Guerby 2002-02-07 5:46 ` Cannot allocate 92625564 bytes after allocating 198356992 bytes Dimitri Frederickx [not found] ` <ho8za5ijlt.fsf@gee.suse.de> 2002-02-07 11:52 ` Loop unrolling-related SPEC regressions? Laurent Guerby 2002-02-01 11:14 ` Joe Buck 2002-02-04 8:45 ` Andreas Jaeger 2002-02-04 10:58 ` Jan Hubicka 2002-02-04 11:07 ` Paolo Carlini 2002-02-04 12:12 ` Andreas Jaeger 2002-02-04 16:36 ` Paolo Carlini 2002-02-04 21:34 ` Tim Prince 2002-02-05 4:32 ` Jan Hubicka 2002-02-05 14:05 ` Geoff Keating 2002-02-06 3:32 ` Jan Hubicka 2002-02-05 20:57 ` Tim Prince 2002-02-04 11:20 ` Joe Buck 2002-02-04 11:33 ` Jan Hubicka 2002-02-04 11:47 ` Jan Hubicka 2002-02-05 9:59 ` David Edelsohn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).