[llvm-dev] [GSoC 2016] Enabling Polyhedral Optimizations in Julia - Midterm Report

[Viral Shah via llvm-dev]

I am looking forward to trying this out when it is ready!

-viral

On Wednesday, June 22, 2016 at 7:39:54 AM UTC-7, Tobias Grosser wrote:
>
> On Wed, Jun 22, 2016, at 02:15 AM, Matthias Reisinger via llvm-dev 
> wrote: 
> > Dear Community, 
>
> Hi Matthias, 
>
> thank you a lot for this update! 
>   
> > in an earlier post, students working on LLVM were asked to provide a 
> > short 
> > report on 
> > their GSoC project. in the following I want to give an overview on the 
> > current status of my 
> > GSoC project and outline my next planned activities. Since my mentoring 
> > organization is Julia, 
> > I also send this to the according mailing list. 
> > 
> > *1. Activities so far:* 
> > 
> > As described in my proposal [1], I am working on making available 
> Polly's 
> > optimizations on Julia. 
> > Within the pull-requests [2] and [3] I integrated Polly into Julia's 
> > LLVM-based JIT infrastructure. 
> > Polly can now be explicitly used to optimize Julia functions that are 
> > annotated with the newly 
> > introduced `@polly` macro. You may also read my blog post [4] on this 
> > topic, which illustrates how 
> > these new features can be used in Julia. In a next step I used first 
> > micro 
> > benchmarks to analyze 
> > the LLVM code that Julia produces internally and tried to determine 
> > characteristics of the produced 
> > code that prevents Polly from applying its optimizations. For a more 
> > comprehensive evaluation, 
> > I ported the PolyBench benchmark suite to Julia. My recent blog post [5] 
> > provides more details on this. 
> > 
> > These benchmarks helped to identify Julia constructs which hinder 
> Polly's 
> > SCoP detection. `for`-loops 
> > for which both the lower and the upper bound are parametric are lowered 
> > to 
> > LLVM code that restrain 
> > ScalarEvolution analysis and has been discussed in the bug report at 
> [6]. 
> > It was possible to solve 
> > this problem and I will shortly supply a patch for this. Another 
> language 
> > construct that is lowered to 
> > LLVM IR that limits the optimization potential are Julia's `StepRange`s. 
> > More concretely, this regards 
> > loops of the form `for i = lower_bound:step:upper_bound`. They will 
> > prevent 
> > optimizations especially 
> > when occurring inside other loops. 
>
> Very good work indeed! Thanks for upstreaming the first patches and for 
> tracking down all the mismatches that today make optimizations more 
> difficult than necessary! It seems -- despite it certainly requiring 
> effort -- most of the changes look tracktable. Looking forward to see 
> them resolved one-by-one. 
>
> Also, thank you for writing a PollyBench-Julia version. This is indeed a 
> great tool to test your work and 
> obviously gives some nice data to talk about in your blog post. 
>
> Best, 
> Tobias 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160709/d8308b06/attachment.html>