search for: simple_types_constant_folding

...ith this tester). Ciao, Duncan. > Significant changes in test results: > GCCAS: > singlesource/Benchmarks/Adobe-C++/functionobjects: -102.68% (0.5960 => 1.2080) > singlesource/Benchmarks/Adobe-C++/loop_unroll: -44.04% (5.3323 => 7.6804) > singlesource/Benchmarks/Adobe-C++/simple_types_constant_folding: -10.34% (5.6883 => 6.2763) > singlesource/Benchmarks/Adobe-C++/simple_types_loop_invariant: -19.15% (3.4882 => 4.1562) > singlesource/Benchmarks/Adobe-C++/stepanov_abstraction: -97.63% (1.0080 => 1.9921) > singlesource/Benchmarks/Adobe-C++/stepanov_vector: -171.51% (0.8280 =&g...

...;baseline=11&aggregation_fn=median The "Polly-NoCodeGen" case is mainly used to compare the compile-time performance for the polly-detect pass. As shown in the results, our patch file could significantly reduce the compile-time overhead for some benchmarks such as tramp3dv4 (24.2%), simple_types_constant_folding(12.6%), oggenc(9.1%), loop_unroll(7.8%) The "Polly-opt" case is used to compare the whole compile-time performance of Polly. Since our patch file mainly affects the Polly-Detect pass, it shows similar performance to "Polly-NoCodeGen". As shown in results, it reduces the compil...

...compile-time >> performance for the polly-detect pass. As shown in the results, our >> patch file could significantly reduce the compile-time overhead for some >> benchmarks such as tramp3dv4 >> <http://188.40.87.11:8000/db_default/v4/nts/16/graph?test.355=2> (24.2%), simple_types_constant_folding >> <http://188.40.87.11:8000/db_default/v4/nts/16/graph?test.366=2>(12.6%), >> oggenc >> <http://188.40.87.11:8000/db_default/v4/nts/16/graph?test.331=2>(9.1%), >> loop_unroll >> <http://188.40.87.11:8000/db_default/v4/nts/16/graph?test.235=2>(7.8%) &...

.../ type, don't do the transformation. > if (FromLegal && !ToLegal) > > > Running on a little A core, in the llvm test suite I am seeing these > changes: > > MultiSource/Benchmarks/BitBench/uudecode/uudecode > 3.38% > SingleSource/Benchmarks/Adobe-C++/simple_types_constant_folding > -35.04% > MultiSource/Benchmarks/Trimaran/enc-pc1/enc-pc1 > -17.92% > SingleSource/Benchmarks/Adobe-C++/simple_types_loop_invariant > -8.57% > External/SPEC/CINT2000/253.perlbmk/253.perlbmk > -3.43% > MultiSource/Benchmarks/MiBench/telecomm-...

...e, and the result would be an illegal // type, don't do the transformation. if (FromLegal && !ToLegal) Running on a little A core, in the llvm test suite I am seeing these changes: MultiSource/Benchmarks/BitBench/uudecode/uudecode 3.38% SingleSource/Benchmarks/Adobe-C++/simple_types_constant_folding -35.04% MultiSource/Benchmarks/Trimaran/enc-pc1/enc-pc1 -17.92% SingleSource/Benchmarks/Adobe-C++/simple_types_loop_invariant -8.57% External/SPEC/CINT2000/253.perlbmk/253.perlbmk -3.43% MultiSource/Benchmarks/MiBench/telecomm-gsm/telecomm-gsm -3.36% MultiSou...

...d to compare the compile-time > performance for the polly-detect pass. As shown in the results, our > patch file could significantly reduce the compile-time overhead for some > benchmarks such as tramp3dv4 > <http://188.40.87.11:8000/db_default/v4/nts/16/graph?test.355=2> (24.2%), simple_types_constant_folding > <http://188.40.87.11:8000/db_default/v4/nts/16/graph?test.366=2>(12.6%), > oggenc > <http://188.40.87.11:8000/db_default/v4/nts/16/graph?test.331=2>(9.1%), > loop_unroll > <http://188.40.87.11:8000/db_default/v4/nts/16/graph?test.235=2>(7.8%) Very nice! Though I...

...=24&baseline=24 The only difference between the two runs is whether they use the r187102 patch file, i.e., run_id=18 is with the r187102 patch file, while run_id=24 is without the r187102 patch file. Results show that this patch file significantly reduces compile time for tramp3d-v4(24.41%), simple_types_constant_folding(13.47%) and oggenc(9.68%). It does not affect the execution performance at all since it only removes some string operations for debugging. Cheers, Star Tan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/2013...

Example: define i8 @narrow_add(i8 %x, i8 %y) { %x32 = zext i8 %x to i32 %y32 = zext i8 %y to i32 %add = add nsw i32 %x32, %y32 %tr = trunc i32 %add to i8 ret i8 %tr } With no data-layout or with an x86 target where 8-bit integer is in the data-layout, we reduce to: $ ./opt -instcombine narrowadd.ll -S define i8 @narrow_add(i8 %x, i8 %y) { %add = add i8 %x, %y ret i8 %add } But on

...t;>> performance for the polly-detect pass. As shown in the results, our >>> patch file could significantly reduce the compile-time overhead for some >>> benchmarks such as tramp3dv4 >>> <http://188.40.87.11:8000/db_default/v4/nts/16/graph?test.355=2> (24.2%), simple_types_constant_folding >>> <http://188.40.87.11:8000/db_default/v4/nts/16/graph?test.366=2>(12.6%), >>> oggenc >>> <http://188.40.87.11:8000/db_default/v4/nts/16/graph?test.331=2>(9.1%), >>> loop_unroll >>> <http://188.40.87.11:8000/db_default/v4/nts/16/graph?te...

...rks/Misc/flops-19.30% SingleSource/Benchmarks/Misc/himenobmtxpa-12.94% MultiSource/Benchmarks/VersaBench/ecbdes/ecbdes-12.68% MultiSource/Benchmarks/ASCI_Purple/SMG2000/smg2000-10.68% Unfortunately, there are also two serious execution-time performance regressions: SingleSource/Benchmarks/Adobe-C++/simple_types_constant_folding204.19% SingleSource/Benchmarks/Polybench/linear-algebra/solvers/dynprog/dynprog44.58% By looking into the simple_types_constant_folding benchmark, I find it is mainly caused by the unexpected impact of the createPromoteMemoryToRegisterPass(). Removing "createPromoteMemoryToRegisterPass" w...

At 2013-09-09 13:07:07,"Tobias Grosser" <tobias at grosser.es> wrote: >On 09/09/2013 05:18 AM, Star Tan wrote: >> >> At 2013-09-09 05:52:35,"Tobias Grosser" <tobias at grosser.es> wrote: >> >>> On 09/08/2013 08:03 PM, Star Tan wrote: >>> Also, I wonder if your runs include the dependence analysis. If this is >>> the

...s with a pinch > of salt (a > pinch is about +-10% in my experience with this tester). Awesome Duncan, thank you for working on this! From the LLC tests, I see: > LLC: > singlesource/Benchmarks/Adobe-C++/loop_unroll: 14.13% (3.75 => 3.22) > singlesource/Benchmarks/Adobe-C++/simple_types_constant_folding: > 69.51% (6.92 => 2.11) > singlesource/Benchmarks/CoyoteBench/fftbench: -563.16% (0.57 => 3.78) > singlesource/Benchmarks/Misc-C++/ray: 6.45% (7.60 => 7.11) > singlesource/Benchmarks/Misc-C++/sphereflake: 12.32% (6.09 => 5.34) > singlesource/Benchmarks/Misc-C++/stepano...

...tput/assembler +2.1% MultiSource/Benchmarks/Prolangs-C/unix-tbl/Output/unix-tbl +2.3% MultiSource/Benchmarks/Prolangs-C/gnugo/Output/gnugo +2.4% External/SPEC/CFP2000/179.art/Output/179.art +2.5% SingleSource/Benchmarks/Adobe-C++/Output/functionobjects +3.3% SingleSource/Benchmarks/Adobe-C++/Output/simple_types_constant_folding +3.3% External/SPEC/CINT2006/471.omnetpp/Output/471.omnetpp +7.1% MultiSource/Benchmarks/Prolangs-C/cdecl/Output/cdecl Targeting x86-64 PIC -O2: -5.3% MultiSource/Benchmarks/ASCI_Purple/SMG2000/Output/smg2000 -5.1% MultiSource/Applications/SIBsim4/Output/SIBsim4 -4.7% External/SPEC/CINT2006/401.bz...

...erformance for the polly-detect pass. As shown in the results, our >>>> patch file could significantly reduce the compile-time overhead for some >>>> benchmarks such as tramp3dv4 >>>> <http://188.40.87.11:8000/db_default/v4/nts/16/graph?test.355=2> (24.2%), simple_types_constant_folding >>>> <http://188.40.87.11:8000/db_default/v4/nts/16/graph?test.366=2>(12.6%), >>>> oggenc >>>> <http://188.40.87.11:8000/db_default/v4/nts/16/graph?test.331=2>(9.1%), >>>> loop_unroll >>>> <http://188.40.87.11:8000/db_defaul...

...4 0.0136 > External/SPEC/CINT2006/401_bzip2/401_bzip2.compile 5.09% 2.1246 2.2328 0.0027 > External/SPEC/CINT2006/473_astar/473_astar.compile 5.07% 1.2970 1.3628 0.0028 > SingleSource/Benchmarks/Adobe-C++/loop_unroll.compile 5.07% 3.2894 3.4561 0.0073 > SingleSource/Benchmarks/Adobe-C++/simple_types_constant_folding.compile 4.95% > 2.5774 2.7051 0.0062 > MultiSource/Applications/siod/siod.compile 4.95% 2.2539 2.3655 0.0032 > SingleSource/Benchmarks/Misc-C++-EH/spirit.compile 4.95% 8.5869 9.0116 0.0067 > MultiSource/Applications/hexxagon/hexxagon.compile 4.93% 1.3692 1.4367 0.0063 > SingleSource/...

...rks/Misc/flops-19.30% SingleSource/Benchmarks/Misc/himenobmtxpa-12.94% MultiSource/Benchmarks/VersaBench/ecbdes/ecbdes-12.68% MultiSource/Benchmarks/ASCI_Purple/SMG2000/smg2000-10.68% Unfortunately, there are also two serious execution-time performance regressions: SingleSource/Benchmarks/Adobe-C++/simple_types_constant_folding204.19% SingleSource/Benchmarks/Polyb! ench/linear-algebra/solvers/dynprog/dynprog44.58% By looking into the simple_types_constant_folding benchmark, I find it is mainly caused by the unexpected impact of the createPromoteMemoryToRegisterPass(). Removing "createPromoteMemoryToRegisterPass"...

...; External/SPEC/CINT2006/401_bzip2/401_bzip2.compile 5.09% 2.1246 2.2328 0.0027 >> External/SPEC/CINT2006/473_astar/473_astar.compile 5.07% 1.2970 1.3628 0.0028 >> SingleSource/Benchmarks/Adobe-C++/loop_unroll.compile 5.07% 3.2894 3.4561 0.0073 >> SingleSource/Benchmarks/Adobe-C++/simple_types_constant_folding.compile 4.95% >> 2.5774 2.7051 0.0062 >> MultiSource/Applications/siod/siod.compile 4.95% 2.2539 2.3655 0.0032 >> SingleSource/Benchmarks/Misc-C++-EH/spirit.compile 4.95% 8.5869 9.0116 0.0067 >> MultiSource/Applications/hexxagon/hexxagon.compile 4.93% 1.3692 1.4367 0.0063 &g...

.../ type, don't do the transformation. > if (FromLegal && !ToLegal) > > > Running on a little A core, in the llvm test suite I am seeing these > changes: > > MultiSource/Benchmarks/BitBench/uudecode/uudecode > 3.38% > SingleSource/Benchmarks/Adobe-C++/simple_types_constant_folding > -35.04% > MultiSource/Benchmarks/Trimaran/enc-pc1/enc-pc1 > -17.92% > SingleSource/Benchmarks/Adobe-C++/simple_types_loop_invariant > -8.57% > External/SPEC/CINT2000/253.perlbmk/253.perlbmk > -3.43% > MultiSource/Benchmarks/MiBench/telecomm-...

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".

...ce/Benchmarks/Adobe-C++/stepanov_abstraction | * | * | SingleSource/Benchmarks/Adobe-C++/stepanov_vector | * | * | SingleSource/Benchmarks/Adobe-C++/simple_types_loop_invariant | * | * | SingleSource/Benchmarks/Adobe-C++/simple_types_constant_folding | * | * | SingleSource/Benchmarks/CoyoteBench/huffbench | * | * | SingleSource/Benchmarks/CoyoteBench/fftbench | * | * | SingleSource/Benchmarks/CoyoteBench/lpbench | * | *...