search for: preoptimizations

...so further canonicalication is required. The minimal sequence of optimization passes for your example is: opt -mem2reg -instcombine -simplifycfg -loop-rotate -indvars 2. -enable-iv-rewrite LLVM recently disabled by default the induction variable rewrite. This feature is necessary for the Polly preoptimizations. Hence, you need to reenable it with the above flag during preoptimization. -> opt -mem2reg -instcombine -simplifycfg -loop-rotate -indvars -enable-iv-rewrite test.s -S > test.preopt.ll In general I use an even longer sequence of preoptimizations. This sequence is built directly into P...

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;

Hi Tobias, thanks for the answer. I'll try to give a look to the code you pointed me to , and I'll try to make the modification myself. I'm new to LLVM and Polly, but the code of both seem clean and understandable, so I hope to be able to do it myself. In case I'll ask here for support :) Marcello 2011/10/1 Tobias Grosser <tobias at grosser.es>: > On 10/01/2011 03:26

...ired. > > The minimal sequence of optimization passes for your example is: > opt -mem2reg -instcombine -simplifycfg -loop-rotate -indvars > > 2. -enable-iv-rewrite > > LLVM recently disabled by default the induction variable rewrite. This > feature is necessary for the Polly preoptimizations. Hence, you need to > reenable it with the above flag during preoptimization. > > -> opt -mem2reg -instcombine -simplifycfg -loop-rotate -indvars > -enable-iv-rewrite test.s -S > test.preopt.ll > > > > In general I use an even longer sequence of preoptimizations. This...

Here are some notes from the scalability session of last week''s Rails camp. They were entered by another session participant and are posted at: http://www.rubyonrailscamp.com/10%3A15%2Bsession%2B-%2Bscaling The key points from my point of view: - the Ruby VM is sketchy, rather like the Java VM around 1997 - the single threaded nature of Rails dispatch handling means we may incur a

At 2013-08-16 12:44:02,"Tobias Grosser" <tobias at grosser.es> wrote: >Hi, > >I tried to reproduce your findings, 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

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 08/16/2013 02:42 AM, Star Tan wrote: > At 2013-08-16 12:44:02,"Tobias Grosser" <tobias at grosser.es> wrote: >> Hi, >> >> I tried to reproduce your findings, 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

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