search for: 253_perlbmk

...1560 79.3658 0.1151 > MultiSource/Applications/d/make_dparser.compile 5.60% 3.0244 3.1938 0.0059 > External/SPEC/CINT95/130_li/130_li.compile 5.60% 1.6850 1.7793 0.0121 > SingleSource/Benchmarks/Misc-C++/stepanov_container.compile 5.59% 0.9634 1.0173 > 0.0025 > External/SPEC/CINT2000/253_perlbmk/253_perlbmk.compile 5.58% 13.0643 13.7938 0.0156 > MultiSource/Applications/lua/lua.compile 5.56% 3.9109 4.1285 0.0105 > External/SPEC/CFP2006/444_namd/444_namd.compile 5.54% 6.8800 7.2614 0.0155 > MultiSource/Benchmarks/MiBench/consumer-jpeg/consumer-jpeg.compile 5.52% 4.5839 > 4.8371...

...'s concerns, and the impact/dependence upon link-time tool should be clarified before disabling this pass. On the other hand, actually the test on our hardware shows disabling this pass without LTO considered, some spec benchmarks would have big regressions, (positive is bad) spec.cpu2000.ref.253_perlbmk 3.27% spec.cpu2000.ref.254_gap 3.18% although I do see some improvements like below, (negative is good) spec.cpu2006.ref.400_perlbench -1.90% spec.cpu2006.ref.471_omnetpp -1.64% spec.cpu2006.ref.482_sphinx3 -1.03% Thanks, -Jiangning 2015-02-26 20:09 GMT+08:00 Renato Golin <renato.golin at l...

...>> MultiSource/Applications/d/make_dparser.compile 5.60% 3.0244 3.1938 0.0059 >> External/SPEC/CINT95/130_li/130_li.compile 5.60% 1.6850 1.7793 0.0121 >> SingleSource/Benchmarks/Misc-C++/stepanov_container.compile 5.59% 0.9634 1.0173 >> 0.0025 >> External/SPEC/CINT2000/253_perlbmk/253_perlbmk.compile 5.58% 13.0643 13.7938 0.0156 >> MultiSource/Applications/lua/lua.compile 5.56% 3.9109 4.1285 0.0105 >> External/SPEC/CFP2006/444_namd/444_namd.compile 5.54% 6.8800 7.2614 0.0155 >> MultiSource/Benchmarks/MiBench/consumer-jpeg/consumer-jpeg.compile 5.52% 4.5839...

...ef.179_art 13.44% > spec.cpu2000.ref.256_bzip2 7.80% > spec.cpu2000.ref.186_crafty 3.69% > spec.cpu2000.ref.175_vpr 2.96% > spec.cpu2000.ref.176_gcc 1.77% > spec.cpu2000.ref.252_eon 1.77% > spec.cpu2000.ref.254_gap 1.19% > spec.cpu2000.ref.197_parser 1.15% > spec.cpu2000.ref.253_perlbmk 1.11% > spec.cpu2000.ref.300_twolf -1.04% > > So we can see almost all got worse performance. > > The command line option I'm using is "-O3 -std=gnu89 -ffast-math -fslp-vectorize -fvectorize -mcpu=cortex-a57 -mllvm -use-cfl-aa -mllvm -use-cfl-aa-in-codegen" > >...

Hello everyone, One of Google's summer interns, George Burgess IV, created an implementation of the CFL pointer-aliasing analysis algorithm, and this has now been added to LLVM trunk. Now we should determine whether it is worthwhile adding this to the default optimization pipeline. For ease of testing, I've added the command line option -use-cfl-aa which will cause the CFL analysis to be

...cpu2000.ref.256_bzip2 7.80% >> spec.cpu2000.ref.186_crafty 3.69% >> spec.cpu2000.ref.175_vpr 2.96% >> spec.cpu2000.ref.176_gcc 1.77% >> spec.cpu2000.ref.252_eon 1.77% >> spec.cpu2000.ref.254_gap 1.19% >> spec.cpu2000.ref.197_parser 1.15% >> spec.cpu2000.ref.253_perlbmk 1.11% >> spec.cpu2000.ref.300_twolf -1.04% >> >> So we can see almost all got worse performance. >> >> The command line option I'm using is "-O3 -std=gnu89 -ffast-math >> -fslp-vectorize -fvectorize -mcpu=cortex-a57 -mllvm -use-cfl-aa >> -mllvm -...

...ef.179_art 13.44% > spec.cpu2000.ref.256_bzip2 7.80% > spec.cpu2000.ref.186_crafty 3.69% > spec.cpu2000.ref.175_vpr 2.96% > spec.cpu2000.ref.176_gcc 1.77% > spec.cpu2000.ref.252_eon 1.77% > spec.cpu2000.ref.254_gap 1.19% > spec.cpu2000.ref.197_parser 1.15% > spec.cpu2000.ref.253_perlbmk 1.11% > spec.cpu2000.ref.300_twolf -1.04% > > So we can see almost all got worse performance. > > The command line option I'm using is "-O3 -std=gnu89 -ffast-math > -fslp-vectorize -fvectorize -mcpu=cortex-a57 -mllvm -use-cfl-aa > -mllvm -use-cfl-aa-in-codegen"...

Hi all, I've started looking at the GlobalMerge pass, enabled by default on ARM and AArch64. I think we should reconsider that, at least for AArch64. As is, the pass just merges all globals together, in groups of 4KB (AArch64, 128B on ARM). At the time it was enabled, the general thinking was "it's almost free, it doesn't affect performance much, we might as well use it".

On 26 February 2015 at 00:57, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > -- A way forward > One obvious way to improve it is: look at uses of globals, and try to > form sets of globals commonly used together. The tricky part is to > define heuristics for "commonly". Also, the pass then becomes much > more expensive. I'm currently looking into

...t; > 1.81% 2.1455 2.1844 0.0035 > MultiSource/Benchmarks/McCat/17-bintr/bintr.compile > <http://llvm.org/perf/db_default/simple/nts/380/graph?pset.0=on&test.MultiSource%2FBenchmarks%2FMcCat%2F17-bintr%2Fbintr.compile=on> > 1.81% 0.0828 0.0843 0.0002 > External/SPEC/CINT2000/253_perlbmk/253_perlbmk.compile > <http://llvm.org/perf/db_default/simple/nts/380/graph?pset.0=on&test.External%2FSPEC%2FCINT2000%2F253_perlbmk%2F253_perlbmk.compile=on> > 1.81% 12.8244 13.0565 0.0142 > SingleSource/UnitTests/SignlessTypes/div.compile > <http://llvm.org/perf/db_default...