search for: fexpensive

...ot have a test directory, and it have an extraneous s directory and an extraneous text file in its root area. Then I ran, under root, R CMD INSTALL Hmisc_1.0.tar.gz, and got: Installing source package `Hmisc' ... libs g77 -fPIC -O3 -fomit-frame-pointer -pipe -s -march=pentium -ffast-math -fexpensive-optimizations -fno-fast-math -c cidxcn.f -o cidxcn.o g77 -fPIC -O3 -fomit-frame-pointer -pipe -s -march=pentium -ffast-math -fexpensive-optimizations -fno-fast-math -c cidxcp.f -o cidxcp.o g77 -fPIC -O3 -fomit-frame-pointer -pipe -s -march=pentium -ffast-math -fexpensive-optimizations -fno-fa...

...ot; -DVERSION=\"1.0rc2\" -DHAVE_DLFCN_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_SQRTF=1 -DHAVE_LOGF=1 -DHAVE_EXPF=1 -DHAVE_ACOSF=1 -DHAVE_ATANF=1 -DHAVE_FREXPF=1 -DHAVE_RINTF=1 -I. -I. -I../include -O20 -ffast-math -mno-ieee-fp -D_REENTRANT -fsigned-char -O2 -march=i686 -mcpu=i686 -fexpensive-optimizations -DUSE_MEMORY_H -c envelope.c -Wp,-MD,.deps/envelope.TPlo -fPIC -DPIC -o .libs/envelope.lo gcc: Internal compiler error: program cc1 got fatal signal 11 Descriptive eh? I strace'd it and it seems to show nothing interesting and since gcc is currently compiled without debuggi...

...ed but when I ran make I got this...a Redhat bug? depmode=gcc /bin/sh ../depcomp \ /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I../include -I. -I../libmp3lame -I.. -O3 -fomit-frame-pointer -ffast-math -funroll-loops -fthread-jumps -malign-double -frerun-loop-opt -fgcse -fexpensive-optimizations -fmove-all-movables -fschedule-insns2 -freduce-all-givs -mpentiumpro -march=pentiumpro -mfancy-math-387 -Wall -pipe -c -o tabinit.lo `test -f tabinit.c || echo './'`tabinit.c rm -f .libs/tabinit.lo gcc -DHAVE_C...

...fferent input files and command line arguments. If you look at the > LLVM llvm-test makefiles, this information is also encoded. From the > 126.gcc makefile, for example, you'll see: > > RUN_OPTIONS := -quiet -funroll-loops -fforce-mem -fcse-follow-jumps > -fcse-skip-blocks -fexpensive-optimizati > ons -fstrength-reduce -fpeephole -fschedule-insns -finline-functions > -fschedule-insns2 -O -o - > > ifeq ($(RUN_TYPE),test) > STDIN_FILENAME = cccp.i > STDOUT_FILENAME = cccp.s > else > STDIN_FILENAME = amptjp.i > STDOUT_FILENAME = amptjp.s > endif >...

...me options, they are different input files and command line arguments. If you look at the LLVM llvm-test makefiles, this information is also encoded. From the 126.gcc makefile, for example, you'll see: RUN_OPTIONS := -quiet -funroll-loops -fforce-mem -fcse-follow-jumps -fcse-skip-blocks -fexpensive-optimizati ons -fstrength-reduce -fpeephole -fschedule-insns -finline-functions -fschedule-insns2 -O -o - ifeq ($(RUN_TYPE),test) STDIN_FILENAME = cccp.i STDOUT_FILENAME = cccp.s else STDIN_FILENAME = amptjp.i STDOUT_FILENAME = amptjp.s endif Note that llvm-test compiles the benchmarks a file at...

Does anyone know the "standard" commandline to compile and run spec95 benchmarks ? I found some scripts in llvm test suite (External/SPEC/CINT95), but I am not sure if they are the *default ref* configurations. <Some of them seem to use smaller problem sizes.> SPEC95 was retired many years ago, so few people around me know how to compile and run them. I am building from

...>> line arguments. If you look at the LLVM llvm-test makefiles, this >> information is also encoded. From the 126.gcc makefile, for example, >> you'll see: >> >> RUN_OPTIONS := -quiet -funroll-loops -fforce-mem -fcse-follow-jumps >> -fcse-skip-blocks -fexpensive-optimizati >> ons -fstrength-reduce -fpeephole -fschedule-insns -finline-functions >> -fschedule-insns2 -O -o - >> >> ifeq ($(RUN_TYPE),test) >> STDIN_FILENAME = cccp.i >> STDOUT_FILENAME = cccp.s >> else >> STDIN_FILENAME = amptjp.i >> STDOUT...

...t suite with a large number of > arrays, but if we do, this kind of analysis should help. > We perform loop vectorization at -O2 now? > > > > > The overall overhead of compiling the whole test suite using our > > analysis is 36.5%. > > Maybe a good candidate for -fexpensive-optimizations? (or -O4?) > It would also be helpful to know what the execution performance impact is to provide context. > > > The biggest overhead is observed in > > "SingleSource/Benchmarks/Misc/flops-5", where we are 5 times slower: > > 0.07s (with our analy...

...ith -O3; I don't know if we have any significant vectorizable loops in the test suite with a large number of arrays, but if we do, this kind of analysis should help. > > The overall overhead of compiling the whole test suite using our > analysis is 36.5%. Maybe a good candidate for -fexpensive-optimizations? (or -O4?) > The biggest overhead is observed in > "SingleSource/Benchmarks/Misc/flops-5", where we are 5 times slower: > 0.07s (with our analysis) compared to 0.0133s(default). > This may not be accurate as the compilation time in both cases are > quite sma...

...atforms. By "best" I mean the > ones > > that produce the fastest code. Here are the values that I currently > use > > for Pentium III or higher CPUs: > > > > -O3 -fomit-frame-pointer -mcpu=athlon -march=athlon \ > > -malign-functions=4 -funroll-loops -fexpensive-optimizations \ > > -fschedule-insns2 -mfancy-math-387 -pipe > > gcc 3.0.3 produces a broken lame executable if you use -O3 with > -funroll-loops. __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions....

Hi Evan, We did an experiment using the LLVM test suite: we compare the overhead of using our analysis to the LLVM default, both with -O2 option. The overall overhead of compiling the whole test suite using our analysis is 36.5%. The biggest overhead is observed in "SingleSource/Benchmarks/Misc/flops-5", where we are 5 times slower: 0.07s (with our analysis) compared to

...ysis only once in the experiment. The analysis is not rerun after it is invalidated by an optimization pass. >> >> >> > >> > The overall overhead of compiling the whole test suite using our >> > analysis is 36.5%. >> >> Maybe a good candidate for -fexpensive-optimizations? (or -O4?) > > > It would also be helpful to know what the execution performance impact is to > provide context. According to our experiments with SPEC, we haven't observed significant impact in terms of execution performance. In our experiments, we run a list of 8 op...

...f we have any significant vectorizable loops in the test suite with a large number of arrays, but if we do, this kind of analysis should help. > >> >> The overall overhead of compiling the whole test suite using our >> analysis is 36.5%. > > Maybe a good candidate for -fexpensive-optimizations? (or -O4?) > >> The biggest overhead is observed in >> "SingleSource/Benchmarks/Misc/flops-5", where we are 5 times slower: >> 0.07s (with our analysis) compared to 0.0133s(default). >> This may not be accurate as the compilation time in both cas...

Currently we have RH7.3 with compiler gcc 2.96.x My mission, should I choose to accept it, involves moving our embedded application to CentOS 4.1 with gcc 3.x Problem is that about 1/2 million lines of code that gcc 2.96 accepts gives fatal fits to the gcc 3.x compiler from CentOS 4.1 I don't know how many fatal fits, as some disguise others etc. "Can't find register to