search for: fourinarow

...marks/FreeBench/distray config.status: executing test/Programs/MultiSource/Benchmarks/FreeBench/distray/test.in commands install: ../test/Programs/MultiSource/Benchmarks/FreeBench/distray/test.in does not exist cd: can't cd to ../../../../../../../test/Programs/MultiSource/Benchmarks/FreeBench/fourinarow config.status: executing test/Programs/MultiSource/Benchmarks/FreeBench/fourinarow/Makefile commands install: ../test/Programs/MultiSource/Benchmarks/FreeBench/fourinarow/Makefile does not exist cd: can't cd to ../../../../../../../test/Programs/MultiSource/Benchmarks/FreeBench/fourinarow conf...

After the removal of llvm/test/Programs and insertion of llvm-test cvs module, the nightly tester showed the following: x86 Linux debug: * hard to say. I think it failed because the check in occurred just as it was starting up. Could someone verify for me? No results were produced. x86 Linux optimized: * everything ran okay * loc graph now shows 550k lines (up 350k!) - not sure

...ions. > > Best Regards, > -- > Arnaud de Grandmaison Arnaud, I've been investigating whether it's safe to apply your patch. I still need to understand why our generated code is slower in some cases. I noticed a particularly bad regression in MultiSource/Benchmarks/FreeBench/fourinarow/fourinarow that I documented here: http://llvm.org/bugs/show_bug.cgi?id=9490 We would like to avoid generating canonical induction variables in IndVarSimplify. Once that work is complete, your patch should no longer be needed. Although in the meantime, it would be nice to understand why promoting...

...wrote: > > Hi Hal, > > I quickly checked the execution profile. It is real. The code changed > significantly. A number of the hottest regions changed. I’ll compare IRs. > Thanks. Obviously a 1000% execution performance regression seems problematic. -Hal > JFYI FreeBench/fourinarow time graph: > http://lnt.llvm.org/db_default/v4/nts/graph?highlight_run=76922&plot.1604615=1349.1604615.3 > > > Its graph in our LNT is more stable. > > Thanks, > > Evgeny > > *From: *Hal Finkel <hfinkel at anl.gov> > *Organization: *Argonne National La...

...arks and SPEC2k6.train on AArch64 Cortex-A57. I > used revisions: Clang 316561, LLVM 316563. > > Options: -O3 -mcpu=cortex-a57 -fomit-frame-pointer > -fexperimental-new-pass-manager > > Regressions: execution time increase > > LNT > > MultiSource/Benchmarks/FreeBench/fourinarow/fourinarow 1018.58% > How real is this? -Hal > MultiSource/Benchmarks/Fhourstones/fhourstones > 9.06% > > MultiSource/Benchmarks/Ptrdist/yacr2/yacr2 > 7.23% > > MultiSource/Benchmarks/Olden/perimeter/peri...

...comparison for llvm 2.6! MultiSource/Applications/hexxagon/hexxagon 1.22 -> 1.14 MultiSource/Applications/lua/lua 0.91 -> 0.84 MultiSource/Applications/obsequi/Obsequi 0.93 -> 0.86 MultiSource/Benchmarks/ASC_Sequoia/CrystalMk/CrystalMk 1.01 -> 0.91 MultiSource/Benchmarks/FreeBench/fourinarow/fourinarow 0.94 -> 0.75 MultiSource/Benchmarks/FreeBench/neural/neural 1.0 -> 0.9 MultiSource/Benchmarks/MiBench/telecomm-gsm/telecomm-gsm 1.06 -> 0.9 MultiSource/Benchmarks/Olden/treeadd/treeadd 11.44 -> 9.89 MultiSource/Benchmarks/Olden/tsp/tsp 1.14 -> 1.02 MultiSource/Be...

...shows relative code size increase (vertical axis) vs relative performance improvement (horizontal axis): > I manually checked the cause of the 3 biggest performance regressions (proprietary benchmark1: -13.70%; MultiSource/Applications/hexxagon/hexxagon: -10.10%; MultiSource/Benchmarks/FreeBench/fourinarow/fourinarow > -5.23%). > For the proprietary benchmark and hexxagon, the code generation didn't change for the hottest parts, so probably is caused by micro-architectural effects of code layout changes. > > This is always good to know, even though it is frustrating. =] > > F...

...size increase (vertical axis) vs > relative performance improvement (horizontal axis): > I manually checked the cause of the 3 biggest performance regressions > (proprietary benchmark1: -13.70%; > MultiSource/Applications/hexxagon/hexxagon: -10.10%; > MultiSource/Benchmarks/FreeBench/fourinarow/fourinarow -5.23%). > For the proprietary benchmark and hexxagon, the code generation didn't > change for the hottest parts, so probably is caused by micro-architectural > effects of code layout changes. > This is always good to know, even though it is frustrating. =] > For fo...

...> MultiSource/Applications/hexxagon/hexxagon 1.22 -> 1.14 > MultiSource/Applications/lua/lua 0.91 -> 0.84 > MultiSource/Applications/obsequi/Obsequi 0.93 -> 0.86 > MultiSource/Benchmarks/ASC_Sequoia/CrystalMk/CrystalMk 1.01 -> 0.91 > MultiSource/Benchmarks/FreeBench/fourinarow/fourinarow 0.94 -> 0.75 > MultiSource/Benchmarks/FreeBench/neural/neural 1.0 -> 0.9 > MultiSource/Benchmarks/MiBench/telecomm-gsm/telecomm-gsm 1.06 -> 0.9 > MultiSource/Benchmarks/Olden/treeadd/treeadd 11.44 -> 9.89 > MultiSource/Benchmarks/Olden/tsp/tsp 1.14 ->...

.../distray > config.status: executing test/Programs/MultiSource/Benchmarks/FreeBench/distray/test.in commands > install: ../test/Programs/MultiSource/Benchmarks/FreeBench/distray/test.in does not exist > cd: can't cd to ../../../../../../../test/Programs/MultiSource/Benchmarks/FreeBench/fourinarow > config.status: executing test/Programs/MultiSource/Benchmarks/FreeBench/fourinarow/Makefile commands > install: ../test/Programs/MultiSource/Benchmarks/FreeBench/fourinarow/Makefile does not exist > cd: can't cd to ../../../../../../../test/Programs/MultiSource/Benchmarks/FreeBench/...

Thanks for running these Kristof! I'd still like to hear from Apple, and if we can get a few more x86 micro-architectures covered that'd be great, but it looks like -O3 is uncontroversial, and the question is whether this makes sense at O2... To me, it would help a lot to know the actual breakdown of benchmarks such as yours Kristof (as they seem to have more codesize impact than others

The 2.7 binaries are available for testing: http://llvm.org/pre-releases/2.7/pre-release1/ You will also find the source tarballs there as well. We rely on the community to help make our releases great, so please help test 2.7 if you can. Please follow these instructions to test 2.7: To test llvm-gcc: 1) Compile llvm from source and untar the llvm-test in the projects directory (name it

Hi all, The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64, which supports natively all types, but it is a real one for several embedded targets, with very few native types. I attached a patch to

...000/255.vortex/Output/255.vortex -1.7% External/SPEC/CINT95/147.vortex/Output/147.vortex -1.6% External/SPEC/CINT2006/483.xalancbmk/Output/483.xalancbmk -1.5% External/SPEC/CINT2000/256.bzip2/Output/256.bzip2 -1.5% External/SPEC/CINT2000/252.eon/Output/252.eon -1.5% MultiSource/Benchmarks/FreeBench/fourinarow/Output/fourinarow -1.5% MultiSource/Benchmarks/mafft/Output/pairlocalalign -1.5% MultiSource/Applications/lua/Output/lua -1.4% MultiSource/Applications/siod/Output/siod -1.4% External/SPEC/CFP2000/177.mesa/Output/177.mesa -1.3% MultiSource/Benchmarks/Bullet/Output/bullet -1.3% MultiSource/Applicati...

...ce/Applications/hexxagon/hexxagon 1.22 -> 1.14 >> MultiSource/Applications/lua/lua 0.91 -> 0.84 >> MultiSource/Applications/obsequi/Obsequi 0.93 -> 0.86 >> MultiSource/Benchmarks/ASC_Sequoia/CrystalMk/CrystalMk 1.01 -> 0.91 >> MultiSource/Benchmarks/FreeBench/fourinarow/fourinarow 0.94 -> 0.75 >> MultiSource/Benchmarks/FreeBench/neural/neural 1.0 -> 0.9 >> MultiSource/Benchmarks/MiBench/telecomm-gsm/telecomm-gsm 1.06 -> 0.9 >> MultiSource/Benchmarks/Olden/treeadd/treeadd 11.44 -> 9.89 >> MultiSource/Benchmarks/Olden/tsp...

...generator generated effectively the same code as the default X86 code generator. Lots of redundant imul/movl/addl sequences. It can't clean it up either. Only unrolling all nested loops permits it to be optimized away, regardless of code generator. Jeff Cohen wrote: > I noticed that fourinarow is one of the programs in which LLVM is much > slower than GCC, so I decided to take a look and see why that is so. > The program has many loops that look like this: > > #define ROWS 6 > #define COLS 7 > > void init_board(char b[COLS][ROWS+1]) > { >...

I noticed that fourinarow is one of the programs in which LLVM is much slower than GCC, so I decided to take a look and see why that is so. The program has many loops that look like this: #define ROWS 6 #define COLS 7 void init_board(char b[COLS][ROWS+1]) { int i,j; for (i=0;i<COLS;i++)...

On Mon, 21 Feb 2005, Jeff Cohen wrote: > I noticed that fourinarow is one of the programs in which LLVM is much slower > than GCC, so I decided to take a look and see why that is so. The program > has many loops that look like this: > > #define ROWS 6 > #define COLS 7 > > void init_board(char b[COLS][ROWS+1]) > { > int i,j...

...tion. So LoopStrengthReduce is not ready for prime time and doesn't actually get used? I might consider whipping it into shape. Does it still have to handle getelementptr in its full generality? Chris Lattner wrote: > On Mon, 21 Feb 2005, Jeff Cohen wrote: > >> I noticed that fourinarow is one of the programs in which LLVM is >> much slower than GCC, so I decided to take a look and see why that is >> so. The program has many loops that look like this: >> >> #define ROWS 6 >> #define COLS 7 >> >> void init_board(char b[COLS][ROWS+1...

...ce/Benchmarks/FreeBench/pifft/pifft | * | * | MultiSource/Benchmarks/FreeBench/pcompress2/pcompress2 | * | * | MultiSource/Benchmarks/FreeBench/neural/neural | * | * | MultiSource/Benchmarks/FreeBench/fourinarow/fourinarow | * | * | MultiSource/Benchmarks/FreeBench/analyzer/analyzer | * | * | MultiSource/Benchmarks/mediabench/jpeg/jpeg-6a/cjpeg | * | * | MultiSource/Benchmarks/mediabench/adpcm/rawdaudio/rawdaudio...