search for: pnogen

Displaying 14 results from an estimated 14 matches for "pnogen".

2013 May 02
0
[LLVMdev] [Polly] GSoC Proposal: Reducing LLVM-Polly Compiling overhead
...ral representation. 3) Polly optimization: analyze > and optimize polyhedral scops. 4) Polly description to LLVM-IR: > translates the polyhedral description back into new LLVM-IR. > > In attched table 1 and 2, pBasic shows the overhead of loading the attached > LLVMPolly.so; pNoGen shows the overhead of step 1) and 2); pNoOpt shows > the overhead of step 1), 2) and 4). So the compiling overhead of Polly > can be divided into three parts: > PolyBench: canonicalization(13%-1%=12%), code generation(248%-13%=235%) > and optimization(393%-248%=145%) MediaBench:canonica...
2013 Apr 26
4
[LLVMdev] [Polly] GSoC Proposal: Reducing LLVM-Polly Compiling overhead
Hi all, I have updated my GSoS proposal: "FastPolly: Reducing LLVM-Polly Compiling overhead" (https://gist.github.com/tanstar/5441808). I think the pass ordering problem you discussed early can be also investigated in this project! Is there any comment or advice about my proposal? I appreciate all your help and advice. Thanks, Star Tan Proposal:
2013 Aug 02
1
[LLVMdev] [Polly] Update of Polly compile-time performance on LLVM test-suite
...really have a need for it before >>>switching to it. >>> >> I have evaluated Polly compile-time performance for the following options: >> >> clang: clang -O3 (runid: 14) >> >> pBasic: clang -O3 -load LLVMPolly.so (runid:15) >> >> pNoGen: pollycc -O3 -mllvm -polly-optimizer=none -mllvm -polly-code-generator=none (runid:16) >> >> pNoOpt: pollycc -O3 -mllvm -polly-optimizer=none (runid:17) >> >> pOpt: pollycc -O3 (runid:18) >> >> For example, you can view the comparison between "clang&qu...
2013 Sep 08
2
[LLVMdev] [Polly] Compile-time and Execution-time analysis for the SCEV canonicalization
...experiments about Polly canonicalization passes and I found the SCEV canonicalization has significant impact on both compile-time and execution-time performance. Detailed results for SCEV and default canonicalization can be viewed on: http://188.40.87.11:8000/db_default/v4/nts/32 (or 33, 34) *pNoGen with SCEV canonicalization (run 32): -O3 -Xclang -load -Xclang LLVMPolly.so -mllvm -polly -mllvm -polly-optimizer=none -mllvm -polly-code-generator=none -mllvm -polly-codegen-scev *pNoGen with default canonicalization (run 33): -O3 -Xclang -load -Xclang LLVMPolly.so -mllvm -polly -mllvm -polly-o...
2013 Aug 01
4
[LLVMdev] [Polly] Update of Polly compile-time performance on LLVM test-suite
...p scop detection actually helps here. >As this is a larger patch, we should really have a need for it before >switching to it. > I have evaluated Polly compile-time performance for the following options: clang: clang -O3 (runid: 14) pBasic: clang -O3 -load LLVMPolly.so (runid:15) pNoGen: pollycc -O3 -mllvm -polly-optimizer=none -mllvm -polly-code-generator=none (runid:16) pNoOpt: pollycc -O3 -mllvm -polly-optimizer=none (runid:17) pOpt: pollycc -O3 (runid:18) For example, you can view the comparison between "clang" and "pNoGen" with: http://188.40.87.11:8...
2013 Aug 01
0
[LLVMdev] [Polly] Update of Polly compile-time performance on LLVM test-suite
...s this is a larger patch, we should really have a need for it before >>switching to it. >> > I have evaluated Polly compile-time performance for the following options: > > clang: clang -O3 (runid: 14) > > pBasic: clang -O3 -load LLVMPolly.so (runid:15) > > pNoGen: pollycc -O3 -mllvm -polly-optimizer=none -mllvm -polly-code-generator=none (runid:16) > > pNoOpt: pollycc -O3 -mllvm -polly-optimizer=none (runid:17) > > pOpt: pollycc -O3 (runid:18) > > For example, you can view the comparison between "clang" and "pNoGen&quo...
2013 Sep 08
0
[LLVMdev] [Polly] Compile-time and Execution-time analysis for the SCEV canonicalization
...canonicalization passes and I found the SCEV canonicalization has significant impact on both compile-time and execution-time performance. Interesting. > Detailed results for SCEV and default canonicalization can be viewed on: http://188.40.87.11:8000/db_default/v4/nts/32 (or 33, 34) > *pNoGen with SCEV canonicalization (run 32): -O3 -Xclang -load -Xclang LLVMPolly.so -mllvm -polly -mllvm -polly-optimizer=none -mllvm -polly-code-generator=none -mllvm -polly-codegen-scev > *pNoGen with default canonicalization (run 33): -O3 -Xclang -load -Xclang LLVMPolly.so -mllvm -polly -mllvm -p...
2013 Jul 31
0
[LLVMdev] [Polly] Update of Polly compile-time performance on LLVM test-suite
On 07/30/2013 10:03 AM, Star Tan wrote: > Hi Tobias and all Polly developers, > > I have re-evaluated the Polly compile-time performance using newest > LLVM/Polly source code. You can view the results on > http://188.40.87.11:8000 > <http://188.40.87.11:8000/db_default/v4/nts/16?compare_to=9&baseline=9&aggregation_fn=median>. > > Especially, I also evaluated
2013 Jul 30
3
[LLVMdev] [Polly] Update of Polly compile-time performance on LLVM test-suite
Hi Tobias and all Polly developers, I have re-evaluated the Polly compile-time performance using newest LLVM/Polly source code. You can view the results on http://188.40.87.11:8000. Especially, I also evaluated our r187102 patch file that avoids expensive failure string operations in normal execution. Specifically, I evaluated two cases for it: Polly-NoCodeGen: clang -O3 -load
2013 Sep 09
4
[LLVMdev] [Polly] Compile-time and Execution-time analysis for the SCEV canonicalization
...sses and I found the SCEV canonicalization has significant impact on both compile-time and execution-time performance. > >Interesting. > >> Detailed results for SCEV and default canonicalization can be viewed on: http://188.40.87.11:8000/db_default/v4/nts/32 (or 33, 34) >> *pNoGen with SCEV canonicalization (run 32): -O3 -Xclang -load -Xclang LLVMPolly.so -mllvm -polly -mllvm -polly-optimizer=none -mllvm -polly-code-generator=none -mllvm -polly-codegen-scev >> *pNoGen with default canonicalization (run 33): -O3 -Xclang -load -Xclang LLVMPolly.so -mllvm -polly -mllv...
2013 May 03
2
[LLVMdev] [Polly] GSoC Proposal: Reducing LLVM-Polly Compiling overhead
...e checkouts of LLVM, Polly, isl, cloog and polybench. > Table 1 and table 2 show the compile-time overhead of Polly. Five cases are tested: > (alias pollycc="clang -O3 -load LLVMPolly.so -mllvm -polly) > * **clang**: clang -O3 > * **pBasic**: clang -O3 -load LLVMPolly.so > * **pNoGen**: pollycc -O3 -mllvm -polly-optimizer=none -mllvm -polly-code-generatorr=none > * **pNoOpt**: pollycc -O3 -mllvm -polly-optimizer=none > * **pOpt**: pollycc -O3 You probably want to add a couple of additional parameters here to ensure we detect all scops in polybench. I would add -mllvm -...
2013 May 03
0
[LLVMdev] [Polly] GSoC Proposal: Reducing LLVM-Polly Compiling overhead
Dear Tobias, Thank you very much for your very helpful advice. Yes, -debug-pass and -time-passes are two very useful and powerful options when evaluating the compile-time of each compiler pass. They are exactly what I need! With these options, I can step into details of the compile-time overhead of each pass. I have finished some preliminary testing based on two randomly selected files from
2013 May 02
2
[LLVMdev] [Polly] GSoC Proposal: Reducing LLVM-Polly Compiling overhead
On 04/30/2013 04:13 PM, Star Tan wrote: > Hi all, [...] > How could I find out where the time is spent on between two adjacent Polly passes? Can anyone give me some advice? Hi Star Tan, I propose to do the performance analysis using the 'opt' tool and optimizing LLVM-IR, instead of running it from within clang. For the 'opt' tool there are two commands that should help
2013 May 03
0
[LLVMdev] [Polly] GSoC Proposal: Reducing LLVM-Polly Compiling overhead
...ac8565e3bb1eabe9a587dd5a6ac4d > >> Table 1 and table 2 show the compile-time overhead of Polly. Five cases are tested: >> (alias pollycc="clang -O3 -load LLVMPolly.so -mllvm -polly) >> * **clang**: clang -O3 >> * **pBasic**: clang -O3 -load LLVMPolly.so >> * **pNoGen**: pollycc -O3 -mllvm -polly-optimizer=none -mllvm -polly-code-generatorr=none >> * **pNoOpt**: pollycc -O3 -mllvm -polly-optimizer=none >> * **pOpt**: pollycc -O3 > >You probably want to add a couple of additional parameters here to >ensure we detect all scops in polybench....