search for: 471_omnetpp

...5 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 0.0243 > MultiSource/Applications/treecc/treecc.compile 5.49% 2.1294 2.2464 0.0057 > External/SPEC/CINT2006/471_omnetpp/471_omnetpp.compile 5.45% 37.9810 40.0522 0.0756 > External/Povray/povray.compile 5.45% 15.6471 16.4994 0.0367 > MultiSource/Applications/JM/lencod/lencod.compile 5.43% 16.6604 17.5654 0.0217 > MultiSource/Applications/sqlite3/sqlite3.compile 5.39% 13.7047 14.4433 0.0256 > MultiSource/A...

...sabling 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 linaro.org>: > On 26 February 2015 at 00:57, Ahmed Bougacha <ahmed.bougacha at gmail.com> > wrote: > > -- A way forward > > One obvious way to imp...

...ternal/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 0.0243 >> MultiSource/Applications/treecc/treecc.compile 5.49% 2.1294 2.2464 0.0057 >> External/SPEC/CINT2006/471_omnetpp/471_omnetpp.compile 5.45% 37.9810 40.0522 0.0756 >> External/Povray/povray.compile 5.45% 15.6471 16.4994 0.0367 >> MultiSource/Applications/JM/lencod/lencod.compile 5.43% 16.6604 17.5654 0.0217 >> MultiSource/Applications/sqlite3/sqlite3.compile 5.39% 13.7047 14.4433 0.0256 >&g...

Most of libc++ doesn't have explicit template instantiations, which leads to a pretty significant build time and code size cost when using libc++, since a large number of common templates will be emitted by the compiler and coalesced by the linker. Notably, in include/__config, we have: #ifndef _LIBCPP_EXTERN_TEMPLATE #define _LIBCPP_EXTERN_TEMPLATE(...) #endif whereas before

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

...ltiSource/Benchmarks/MiBench/network-dijkstra/network-dijkstra.compile > <http://llvm.org/perf/db_default/simple/nts/380/graph?pset.0=on&test.MultiSource%2FBenchmarks%2FMiBench%2Fnetwork-dijkstra%2Fnetwork-dijkstra.compile=on> > 1.39% 0.0503 0.0510 0.0002 > External/SPEC/CINT2006/471_omnetpp/471_omnetpp.compile > <http://llvm.org/perf/db_default/simple/nts/380/graph?pset.0=on&test.External%2FSPEC%2FCINT2006%2F471_omnetpp%2F471_omnetpp.compile=on> > 1.39% 37.6816 38.2057 0.0521 > MultiSource/Benchmarks/MallocBench/cfrac/cfrac.compile > <http://llvm.org/perf/db_d...