search for: sphinx3

...spec/2006/fp/C++/447.dealII 46.19 +0.89% spec/2006/fp/C++/450.soplex 42.92 -0.44% spec/2006/fp/C++/453.povray 38.57 -2.25% spec/2006/fp/C/433.milc 24.54 -0.76% spec/2006/fp/C/470.lbm 41.08 +0.26% spec/2006/fp/C/482.sphinx3 47.58 -0.99% spec/2006/int/C++/471.omnetpp 22.06 +1.87% spec/2006/int/C++/473.astar 22.65 -0.12% spec/2006/int/C++/483.xalancbmk 33.69 +4.97% spec/2006/int/C/400.perlbench 33.43 +1.70% spec/2006/int/C/401.bzip2 23.0...

...-1,716 464.h264ref -684 456.hmmer -391 462.libquantum -4 429.mcf -4 471.omnetpp -1,980 400.perlbench -4,176 458.sjeng -338 450.soplex -395 483.xalancbmk -4,183 447.dealII -186 433.milc -34 444.namd -104 453.povray -1,785 482.sphinx3 -112 I propose to factor out the relevant code from BranchFolding into a utility, and call it from BlockPlacement whenever the layout is changed. It is similar to D18226 and D18411 which factor tail duplication into a utility and call it from BlockPlacement. Any thoughts, advice, or co...

...> - > > Recurrences-flt: 22.19% > - > > StatementReordering-flt: 22.15% > - > > Searching-flt: 21.96% > > > SPEC, top improvements: > E&LO: > > - > > bzip2: 9.15% > - > > gcc: 4.03% > - > > sphinx3: 3.8% > - > > H264ref: 3.24% > - > > Perlbench: 3% > > LO: > > - > > bzip2: 7.27% > - > > sphinx3: 3.65% > - > > Namd: 3.08% > - > > Gcc: 3.06% > - > > H264ref: 3.05% > > MO: >...

On Jul 22, 2010, at 4:18 PMPDT, Reza Yazdani wrote: > Hi, > > I ran Spec2006 with -O4. All integer benchmarks passed, but only 8 > out 17 of floating point benchmarks passed. Is this normal or I > made a mistake in my build? Hi Reza. Somebody on Linux should answer, but I don't think it's normal. You may have checked out the source at a moment when it had a bug

Hi, I ran Spec2006 with -O4. All integer benchmarks passed, but only 8 out 17 of floating point benchmarks passed. Is this normal or I made a mistake in my build? Reza -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100722/4c4a81a9/attachment.html>

...RE 459.GemsFDTD -- 0.00150 RE 465.tonto -- 2.40 -- S 470.lbm -- 6.52 -- S 481.wrf -- 0.00140 RE 482.sphinx3 -- 3.19 -- S On Thu, Jul 22, 2010 at 4:59 PM, Dale Johannesen <dalej at apple.com> wrote: > > On Jul 22, 2010, at 4:18 PMPDT, Reza Yazdani wrote: > > Hi, >> >> I ran Spec2006 with -O4. All integer benchmarks passe...

...actusADM 8.31 7.89 5.32% 437.leslie3d 11 11 0.00% 444.namd   16 16 0.00% 447.dealII 25.4 25.4 0.00% 450.soplex 26.1 26.1 0.00% 453.povray 20.5 20.5 0.00% 454.calculix 8.44 8.3 1.69% 459.GemsFDTD  10.7 10.7 0.00% 465.tonto CE CE #VALUE! 470.lbm 38.1 31.5 20.95% 481.wrf 11.6 11.6 0.00% 482.sphinx3 28.2 26.9 4.83% GEOMEAN 15.91486307 15.54419555    2.38% Precise Latencies Benchmark Branch-and-Bound LLVM SPEC Score SPEC Score % Score Difference 400.perlbench 21.2 20.2 4.95% 401.bzip2 13.9 13.6 2.21% 403.gcc 19.6 19.8 -1.01% 429.mcf 20.8 20.5 1.46% 445.gobmk 18.8 18.6 1.08% 456.h...

...small. I only implemented the part 1 (encoding duplication factor) for loop unrolling and loop vectorization. The debug_line size overhead for "-O2 -g1" binary of speccpu C/C++ benchmarks: 433.milc 23.59% 444.namd 6.25% 447.dealII 8.43% 450.soplex 2.41% 453.povray 5.40% 470.lbm 0.00% 482.sphinx3 7.10% 400.perlbench 2.77% 401.bzip2 9.62% 403.gcc 2.67% 429.mcf 9.54% 445.gobmk 7.40% 456.hmmer 9.79% 458.sjeng 9.98% 462.libquantum 10.90% 464.h264ref 30.21% 471.omnetpp 0.52% 473.astar 5.67% 483.xalancbmk 1.46% mean 7.86% Dehao On Thu, Oct 27, 2016 at 11:55 AM, Xinliang David Li <davidxl at g...

...md 16 16 0.00% > 447.dealII 25.4 25.4 0.00% > 450.soplex 26.1 26.1 0.00% > 453.povray 20.5 20.5 0.00% > 454.calculix 8.44 8.3 1.69% > 459.GemsFDTD 10.7 10.7 0.00% > 465.tonto CE CE #VALUE! > 470.lbm 38.1 31.5 20.95% > 481.wrf 11.6 11.6 0.00% > 482.sphinx3 28.2 26.9 4.83% > GEOMEAN 15.91486307 15.54419555 2.38% > > > Precise Latencies > > Benchmark Branch-and-Bound LLVM > > SPEC Score SPEC Score % Score Difference > 400.perlbench 21.2 20.2 4.95% > 401.bzip2 13.9 13.6 2.21% > 403.gcc 19.6 19.8...

...plication factor) for loop unrolling and loop > vectorization. The debug_line size overhead for "-O2 -g1" binary of speccpu > C/C++ benchmarks: > > 433.milc 23.59% > 444.namd 6.25% > 447.dealII 8.43% > 450.soplex 2.41% > 453.povray 5.40% > 470.lbm 0.00% > 482.sphinx3 7.10% > 400.perlbench 2.77% > 401.bzip2 9.62% > 403.gcc 2.67% > 429.mcf 9.54% > 445.gobmk 7.40% > 456.hmmer 9.79% > 458.sjeng 9.98% > 462.libquantum 10.90% > 464.h264ref 30.21% > 471.omnetpp 0.52% > 473.astar 5.67% > 483.xalancbmk 1.46% > mean 7.86% > Dehao...

...sumer-typeset/consumer-typeset 6.02% > > MultiSource/Benchmarks/Trimaran/enc-pc1/enc-pc1 > 5.59% > > MultiSource/Benchmarks/ASC_Sequoia/AMGmk/AMGmk > 5.03% > > SPEC2k6 > > 453.povray 17.11% > > 482.sphinx3 3.44% > > 444.namd 2.89% > > Improvements: execution time decrease > > LNT > > MultiSource/Benchmarks/BitBench/uudecode/uudecode -50.90% > > SingleSource/Benchmarks/Adobe-C++/loop_unroll > -27.75% > > SingleSour...

...00150 RE > 465.tonto -- > 2.40 -- S > 470.lbm -- > 6.52 -- S > 481.wrf -- > 0.00140 RE > 482.sphinx3 -- > 3.19 -- S > > On Thu, Jul 22, 2010 at 4:59 PM, Dale Johannesen <dalej at apple.com> > wrote: > > On Jul 22, 2010, at 4:18 PMPDT, Reza Yazdani wrote: > > Hi, > > I ran Spec2006 with -O4. All integer ben...

...1 11 0.00% > 444.namd 16 16 0.00% > 447.dealII 25.4 25.4 0.00% > 450.soplex 26.1 26.1 0.00% > 453.povray 20.5 20.5 0.00% > 454.calculix 8.44 8.3 1.69% > 459.GemsFDTD 10.7 10.7 0.00% > 465.tonto CE CE #VALUE! > 470.lbm 38.1 31.5 20.95% > 481.wrf 11.6 11.6 0.00% > 482.sphinx3 28.2 26.9 4.83% > GEOMEAN 15.91486307 15.54419555 2.38% > > Precise Latencies > > Benchmark Branch-and-Bound LLVM > > SPEC Score SPEC Score % Score Difference > 400.perlbench 21.2 20.2 4.95% > 401.bzip2 13.9 13.6 2.21% > 403.gcc 19.6 19.8 -1.01% > 429.mcf 20....

...eset 6.02% > > MultiSource/Benchmarks/Trimaran/enc-pc1/enc-pc1 > 5.59% > > MultiSource/Benchmarks/ASC_Sequoia/AMGmk/AMGmk > 5.03% > > SPEC2k6 > > 453.povray 17.11% > > 482.sphinx3 3.44% > > 444.namd 2.89% > > Improvements: execution time decrease > > LNT > > MultiSource/Benchmarks/BitBench/uudecode/uudecode > -50.90% > > SingleSource/Benchmarks/Adobe-C++/loop_unroll >...

...% -9.29% 465.tonto 18.31 14.96 18.65 22.39% -1.81% 4674046 4724002 4875130 -1.06% -4.12% 470.lbm 42.77 39.82 43.49 7.42% -1.65% 19390 21372 21544 -9.27% -10.00% 481.wrf 14.57 14.88 15.10 -2.13% -3.54% 4956659 4873380 5270234 1.71% -5.95% 482.sphinx3 27.12 25.69 25.82 5.55% 5.03% 213919 217765 233070 -1.77% -8.22% ----------------------------------------------------------------------------------------------- geomean 21.20 19.62 20.93 8.05% 1.31% 563864 578104 600126 -2.46% -6.04% Yours - Michael

----- Original Message ----- > From: "Tobias Edler von Koch" <tobias at codeaurora.org> > To: "Daniel Berlin" <dberlin at dberlin.org> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, June 11, 2015 10:02:37 AM > Subject: Re: [LLVMdev] BasicAA unable to analyze recursive PHI nodes > > Hi Daniel,

Do you have an estimate of the debug_line size increase? I guess it will be small. David On Thu, Oct 27, 2016 at 11:39 AM, Dehao Chen <dehao at google.com> wrote: > Motivation: > Many optimizations duplicate code. E.g. loop unroller duplicates the loop > body, GVN duplicates computation, etc. The duplicated code will share the > same debug info with the original code. For

...% -9.29% 465.tonto 18.31 14.96 18.65 22.39% -1.81% 4674046 4724002 4875130 -1.06% -4.12% 470.lbm 42.77 39.82 43.49 7.42% -1.65% 19390 21372 21544 -9.27% -10.00% 481.wrf 14.57 14.88 15.10 -2.13% -3.54% 4956659 4873380 5270234 1.71% -5.95% 482.sphinx3 27.12 25.69 25.82 5.55% 5.03% 213919 217765 233070 -1.77% -8.22% ----------------------------------------------------------------------------------------------- geomean 21.20 19.62 20.93 8.05% 1.31% 563864 578104 600126 -2.46% -6.04% Yours - Michael _______...

I’m River and I’m a compiler engineer at PlayStation. Recently, I’ve been working on an interprocedural outlining (code folding) pass for code size improvement at the IR level. We hit a couple of use cases that the current code size solutions didn’t handle well enough. Outlining is one of the avenues that seemed potentially beneficial. -- Algorithmic Approach -- The general implementation can be

On Fri, May 19, 2017 at 4:01 PM Adam Nemet via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I will run it on Cyclone/AArch64 next week. > FYI, we're still waiting on these Adam... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170530/7cb390ca/attachment.html>