similar to: [LLVMdev] [Polly][GSOC2013] FastPolly -- SCOP Detection Pass

On 06/29/2013 05:04 PM, Star Tan wrote: > Hi all, > > > > I have investigated the compile-time overhead of "Polly Scop Detection" pass based on LNT testing results. > This mail is to share some results I have found. > > > (1) Analysis of "SCOP Detection Pass" for PolyBench (Attached file PolyBench_SCoPs.log) > Experimental results show that the

At 2013-06-30 08:34:34,"Tobias Grosser" <tobias at grosser.es> wrote: >On 06/29/2013 05:04 PM, Star Tan wrote: >> Hi all, >> >> >> >> I have investigated the compile-time overhead of "Polly Scop Detection" pass based on LNT testing results. >> This mail is to share some results I have found. >> >> >> (1) Analysis

On 07/01/2013 06:51 AM, Star Tan wrote: >> Great. Now we have two test cases we can work with. Can you > >> upload the LLVM-IR produced by clang -O0 (without Polly)? > Since tramp3d-v4.ll is to large (19M with 267 thousand lines), I would focus on the oggenc benchmark at firat. > I attached the oggenc.ll (LLVM-IR produced by clang -O0 without Polly), which compressed into the

>Great. Now we have two test cases we can work with. Can you >upload the LLVM-IR produced by clang -O0 (without Polly)? Since tramp3d-v4.ll is to large (19M with 267 thousand lines), I would focus on the oggenc benchmark at firat. I attached the oggenc.ll (LLVM-IR produced by clang -O0 without Polly), which compressed into the file oggenc.tgz. >2) Check why the Polly scop detection is

>> (3) About detecting scop regions in bottom-up order. >> Detecting scop regions in bottom-up order can significantly speed up the scop detection pass. However, as I have discussed with Sebastian, detecting scops in bottom-up order and up-bottom order will lead to different results. As a result, we should not change the detection order. > >Sebastian had a patch for this. Does

At 2013-08-12 01:18:30,"Tobias Grosser" <tobias at grosser.es> wrote: >On 08/10/2013 06:59 PM, Star Tan wrote: >> Hi all, >> >> I have evaluated Polly's performance on LLVM test-suite with latest LLVM (r188054) and Polly (r187981).  Results can be viewed on: http://188.40.87.11:8000. > >Hi Star Tan, > >thanks for the update. >

At 2013-07-31 22:50:57,"Tobias Grosser" <tobias at grosser.es> wrote: >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 >>

On 06/06/2013 11:17 AM, Star Tan wrote: > Hi Tobias, > > > I am recently trying to set up the performance tester for FastPolly project. According to your suggestion, I plan to use the LNT infrastructure to set up the performance tester. For this purpose, I think I should do this job in three steps: > > > First, I will add PolyBench to LLVM test-suite since PolyBench is the

Hi Tobias, I am recently trying to set up the performance tester for FastPolly project. According to your suggestion, I plan to use the LNT infrastructure to set up the performance tester. For this purpose, I think I should do this job in three steps: First, I will add PolyBench to LLVM test-suite since PolyBench is the critical benchmarks for FastPolly. I have adjust the PolyBench-c-3.2 so we

Mmm, this code seems to kill polly: #include <stdio.h> #include <stdlib.h> int main() { char *B; int i,j,k,h; const int x = 0, y=0; B = (char *)malloc(sizeof(char)*1024*1024); for (i = 1; i < 1024; i++) for (j = 1; j < 1024; j++) { if (i+j > 1000) B[j] = i; } printf("Random Value: %d", B[rand() % 1024*1024]); return 0; } running: opt

On 04/26/2013 05:08 AM, tanmx_star wrote: > Hi all, Hi, thanks for the update and sorry for the delay in reviewing. I just had a look at your proposal. > 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!

On 04/08/2011 08:35 PM, Vlad Krylov wrote: > 2011/4/8 ether zhhb<etherzhhb at gmail.com>: >> Hi, >> >> 2011/4/8 Vlad Krylov<krvladislav at gmail.com>: >>> Hi. >>> >>> I see that to detect scops firstly we search for regions in CFG ( by >>> RegionInfo ) and then select regions that answer some requirements ( >>> in

Mmm I found out a very strange behavior (to me) of the SCEV analysis of the loop bound of the external loop I posted. When in ScopDetection it gets the SCEV of the external loop bound in the "isValidLoop()" function with: const SCEV *LoopCount = SE->getBackedgeTakenCount(L); It returns a SCEVCouldNotCompute, but if I change the "if" block inside the loop from: if

Hi, A few tests seem broken for a long time, some for more than a month. Would it possible for respective owners to take a look please? I'm at checkout 133a7e631cee97965e310f0d110739217427fd3d, compiling on Windows 10. These tests fail with Visual Studio 2019: Failing Tests (7): Clang Tools :: clang-tidy/checkers/cert-mem57-cpp-cpp17.cpp Clang Tools ::

2011/4/8 ether zhhb <etherzhhb at gmail.com>: > Hi, > > 2011/4/8 Vlad Krylov <krvladislav at gmail.com>: >> Hi. >> >> I see that to detect scops firstly we search for regions in CFG ( by >> RegionInfo ) and then select regions that answer some requirements ( >> in ScopDetection ). Because only affine expressions in conditions and >> bounds

I add also the output of these commands: [hades at artemis examples]$ ./compile_ex.sh super_simple_loop Printing analysis 'Polly - Detect Scops in functions' for function 'main': [hades at artemis examples]$ modifying it in : #include <stdio.h> int main() { int A[1024]; int j, k=10; for (j = 0; j < 1024; j++) A[j] = k;

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

On 08/15/2013 03:32 AM, Star Tan wrote: > Hi all, Hi, I tried to reproduce your findings, but could not do so. > I have investigated the 6X extra compile-time overhead when Polly compiles the simple nestedloop benchmark in LLVM-testsuite. (http://188.40.87.11:8000/db_default/v4/nts/31?compare_to=28&baseline=28). Preliminary results show that such compile-time overhead is resulted by

On 09/12/2011 04:28 PM, Sebastian Pop wrote: > Hi Alexandra, > > On Thu, Sep 8, 2011 at 13:53, Jimborean Alexandra<xinfinity_a at yahoo.com> wrote: >> I had a look at the CodeGeneration from Polly. Is it possible to use it >> without creating the Scops, by transforming it into a LoopPass? > > Yes. If you don't want to use the autopar of Polly and just rely on

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