[llvm-dev] [GSoC 2016] Enabling Polyhedral Optimizations in Julia - Midterm Report
Tobias Grosser via llvm-dev
llvm-dev at lists.llvm.org
Wed Jun 22 07:39:48 PDT 2016
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
More information about the llvm-dev
mailing list