search for: nestedloop

...ings, but could not do so. Sorry, I did not put all code in my previous email because the code seems a little too long and complicated. You can refer to the detailed C code and LLVM IR code on http://llvm.org/bugs/show_bug.cgi?id=16843 There are four attachments for our C code and LLVM IR code: nestedloop.c (http://llvm.org/bugs/attachment.cgi?id=11043): the simplified C code. nestedloop.ll (http://llvm.org/bugs/attachment.cgi?id=11044): the basic LLVM IR code. nestedloop.preopt.ll (http://llvm.org/bugs/attachment.cgi?id=11045): the preprocessed LLVM IR code. nestedloop.prepare.ll (http://llvm.org/b...

...ainly resulted by some expensive Polly passes such as PollyDependence, PollyOptimization and PollyCodegen. Especially, I notice that the PollyDependence can lead to significant extra compile-time overhead. Its compile-time percentage for some expensive benchmarks can be summarized as: >>      nestedloop:  41.4% (Polly - Calculate dependence) >>      salsa20:       98.5% (Polly - Calculate dependence) >>      seidel-2d:     72.1% (Polly - Calculate dependence) >>      multiplies:     54.3% (Poly -  Calculate dependence) >>      Puzzle:         22.8% (Poly -  Calculate depend...

...the mail. However, the one you submitted >> looked good and was committed. >> >>> With this patch file, we can reduce the compile-time percentage of PollyDependence from 98.5% to 15.3%. Unfortunately, the compile-time percentage of PollyDependence for benchmarks, such as "nestedloop", is still very high. >> >> It would be good to get an up-to-date comparison with the latest patch >> having gone into Polly. > > Yes, you can view the comparison on: > http://188.40.87.11:8000/db_default/v4/nts/26?compare_to=25&baseline=25 I am slightly co...

...ode, this is in fact a good baseline - especially as we did not spend  >too much time optimising this. Yes, we should look into the compile-execution performance trade-off.  I have summarized some benchmarks (compile-time overhead is more than 200%) as follows: SingleSource/Benchmarks/Shootout/nestedloop, compile_time(+6355.56%), execution_time(-99.21%) SingleSource/Benchmarks/Polybench/stencils/seidel-2d/seidel-2d, compile_time(+1275.00%), execution_time (0%) SingleSource/Benchmarks/Shootout-C++/nestedloop, compile_time(+1155.56%), execution_time(-99.23%) MultiSource/Benchmarks/ASC_Sequoia/AMGm...

...> Sorry, I did not put all code in my previous email because the code seems a little too long and complicated. > You can refer to the detailed C code and LLVM IR code on http://llvm.org/bugs/show_bug.cgi?id=16843 > There are four attachments for our C code and LLVM IR code: > > > nestedloop.c (http://llvm.org/bugs/attachment.cgi?id=11043): the simplified C code. > nestedloop.ll (http://llvm.org/bugs/attachment.cgi?id=11044): the basic LLVM IR code. > nestedloop.preopt.ll (http://llvm.org/bugs/attachment.cgi?id=11045): the preprocessed LLVM IR code. > nestedloop.prepare.ll (ht...

...rhead is mainly resulted by some expensive Polly passes such as PollyDependence, PollyOptimization and PollyCodegen. Especially, I notice that the PollyDependence can lead to significant extra compile-time overhead. Its compile-time percentage for some expensive benchmarks can be summarized as: nestedloop: 41.4% (Polly - Calculate dependence) salsa20: 98.5% (Polly - Calculate dependence) seidel-2d: 72.1% (Polly - Calculate dependence) multiplies: 54.3% (Poly - Calculate dependence) Puzzle: 22.8% (Poly - Calculate dependence) As a result, it is critical to i...

...is mainly resulted by some expensive Polly passes such as PollyDependence, PollyOptimization and PollyCodegen. Especially, I notice that the PollyDependence can lead to significant extra compile-time overhead. Its compile-time percentage for some expensive benchmarks can be summarized as: > nestedloop: 41.4% (Polly - Calculate dependence) > salsa20: 98.5% (Polly - Calculate dependence) > seidel-2d: 72.1% (Polly - Calculate dependence) > multiplies: 54.3% (Poly - Calculate dependence) > Puzzle: 22.8% (Poly - Calculate dependence) > >...

...SVC/LinearDependence-flt/LinearDependence-flt-8.18% Second, we find that SCEV canonicalization has both regression and improvement of execution performance compared with default canonicalization. Actually, there are many execution-time regressions such as: SingleSource/Benchmarks/Shootout/nestedloop+16363.64% SingleSource/Benchmarks/Shootout-C++/nestedloop+16200.00% SingleSource/UnitTests/Vectorizer/gcc-loops+107.35% SingleSource/Benchmarks/Polybench/medley/reg_detect/reg_detect+75.00 SingleSource/Benchmarks/Misc/flops-6+40.03% SingleSource/Benchmarks/Mi...

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 the complicated polly-dependence analysis. However, the key seems to be the polly-prepare pass, which introduces a larg...

...owever, the one you submitted >>> looked good and was committed. >>> >>>> With this patch file, we can reduce the compile-time percentage of PollyDependence from 98.5% to 15.3%. Unfortunately, the compile-time percentage of PollyDependence for benchmarks, such as "nestedloop", is still very high. >>> >>> It would be good to get an up-to-date comparison with the latest patch >>> having gone into Polly. >> >> Yes, you can view the comparison on: >>      http://188.40.87.11:8000/db_default/v4/nts/26?compare_to=25&basel...

Hi all, 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 the complicated polly-dependence analysis. However, the key seems to be the polly-prepare pass, which introduces a larg...

...e-flt/LinearDependence-flt-8.18% > > > Second, we find that SCEV canonicalization has both regression and improvement of execution performance compared with default canonicalization. Actually, there are many execution-time regressions such as: > SingleSource/Benchmarks/Shootout/nestedloop+16363.64% > SingleSource/Benchmarks/Shootout-C++/nestedloop+16200.00% Those two have a huge impact. Understanding what is going on here would be nice. > I think the execution-time performance regression is mainly because of the unexpected performance improvements from non-SCEV can...

...case if any more information is required. i also tried the following method. in this method i created the llvm bitcode in my host x86 machine and then copied it to target and from target if i try to run the bitcode using lli tool i am getting the following error. * * *# ../../llvm-2.6-arm/bin/lli nestedloop.bc lli: /home/prasanth/LLVM_ARM/llvm-**target/llvm-2.6/include/llvm/**ADT/ilist.h:197: typename bidirectional_iterator<NodeTy, int>::reference llvm::ilist_iterator<NodeTy>::**operator*() const [with NodeTy = llvm::RecyclerStruct]: Assertion `Traits::getNext(NodePtr) != 0 && &quo...

...he r187102 patch file that we discussed above) Please notice that this patch file will lead to some errors in Polly-tests, so the data shown here can not be regards as confident results. For example, this patch can significantly reduce the compile-time overhead of SingleSource/Benchmarks/Shootout/nestedloop only because it regards the nested loop as an invalid scop and skips all following transformations and optimizations. However, I evaluated it here to see its potential performance impact. Based on the results shown on http://188.40.87.11:8000/db_default/v4/nts/21?compare_to=16&baseline=16&...

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. > There are mainly five new tests and each test is run with 10 samples: > clang (run id = 27): clang -O3 > pollyBasic (run id =

...ve) >> >> Please notice that this patch file will lead to some errors in >> Polly-tests, so the data shown here can not be regards as confident >> results. For example, this patch can significantly reduce the >> compile-time overhead of SingleSource/Benchmarks/Shootout/nestedloop >> <http://188.40.87.11:8000/db_default/v4/nts/19/graph?test.17=2> only >> because it regards the nested loop as an invalid scop and skips all >> following transformations and optimizations. However, I evaluated it >> here to see its potential performance impact. Base...

...hat we discussed above) > > Please notice that this patch file will lead to some errors in > Polly-tests, so the data shown here can not be regards as confident > results. For example, this patch can significantly reduce the > compile-time overhead of SingleSource/Benchmarks/Shootout/nestedloop > <http://188.40.87.11:8000/db_default/v4/nts/19/graph?test.17=2> only > because it regards the nested loop as an invalid scop and skips all > following transformations and optimizations. However, I evaluated it > here to see its potential performance impact. Based on the results...

...;>> Please notice that this patch file will lead to some errors in >>> Polly-tests, so the data shown here can not be regards as confident >>> results. For example, this patch can significantly reduce the >>> compile-time overhead of SingleSource/Benchmarks/Shootout/nestedloop >>> <http://188.40.87.11:8000/db_default/v4/nts/19/graph?test.17=2> only >>> because it regards the nested loop as an invalid scop and skips all >>> following transformations and optimizations. However, I evaluated it >>> here to see its potential performan...

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. There are mainly five new tests and each test is run with 10 samples: clang (run id = 27):  clang -O3 pollyBasic (run id = 28):  clang -O3 -load LLVMPolly.so pollyNoGen (run id = 29):  pollycc -O3 -mllvm -polly-optimizer=none

...ease notice that this patch file will lead to some errors in >>>> Polly-tests, so the data shown here can not be regards as confident >>>> results. For example, this patch can significantly reduce the >>>> compile-time overhead of SingleSource/Benchmarks/Shootout/nestedloop >>>> <http://188.40.87.11:8000/db_default/v4/nts/19/graph?test.17=2> only >>>> because it regards the nested loop as an invalid scop and skips all >>>> following transformations and optimizations. However, I evaluated it >>>> here to see its pot...