[llvm-dev] Polly as an Analysis pass in LLVM

[Hongbin Zheng via llvm-dev]

Hi Johannes,

On Mon, Mar 21, 2016 at 6:35 PM, Johannes Doerfert <
doerfert at cs.uni-saarland.de> wrote:

> Hey Utpal,
>
> First of, I think you made nice process here and have some very good
> ideas of what we could do in the future.
>
> [NOTE: I CC'ed some people that have shown interest in this topic but I
> might have forgotten some, therefor I also added the llvm-dev list.]
>
> For the upcoming GSoC proposal we should slow down a little bit and
> reevaluate our goals. After talking to a couple of LLVM and Polly folks
> at EuroLLVM last week, I hope to have a fairly good idea of how to
> proceed. To this end, I will give you my personal road map that might be
> a good start for the proposal too, though it is not the only way we
> could do this:
>
>   1) Make ScopInfo & DependenceInfo function passes to avoid the
>      RegionPassManager for these Polly analysis parts. [This doesn't
>      need to be the first step but it should be done at some point.]
>   2) Create a secondary ScopDetection & ScopInfo that is restricted to
>      analyze a single loop. We might just create a dummy region for this
>      loop and use the original ScopDetection & ScopInfo. The goal is to
>      make (this secondary) ScopDetection & ScopInfo demand driven and
>      non-dependent on the RegionInfo analysis. [Same as before, this
>      does not need to happen right away.]
>
I really like this direction. In general, we may want to decouple the
ScopDetection/ScopInfo construction logic from the pass logic, such that we
can run the logic ScopDetection and ScopInfo construction in a function
pass, call graph scc pass, or even a loop pass.

For 1), can we always construct a whole function Scop (excluding the entry
block which contains allocas)?

Thanks
Hongbin



>   3) Scan the LLVM source code for uses of ScalarEvolution or reasoning
>      about the execution of basic blocks [this includes thing like loop
>      trip count queries]. These are possible candidates that might
>      profit from the knowledge contained in a "Scop" object.
>   4) Start an API that translates (simple) queries from the LLVM passes
>      to lookups in a Scop. The LLVM pass should never "see" the Scop
>      object or anything related for that matter. It will only require a
>      "PolyhedralInfo" pass and query it.
>   5) Use the above API to augment the information available at the
>      points identified in 3), but only if the available information is
>      not sufficient to apply the intended transformation.
>   6) Evaluate the impact on compile and runtime for each pass that was
>      augmented. Check how often (and for which kind of codes) the
>      polyhedral information was queried and how often it allowed a
>      transformation.
>   7) Go back to 3 but now look for passes/opportunities that would need
>      dependence information, thus the DependenceInfo pass. Then proceed
>      with 4), 5) and 6) for dependences.
>
> Note that not all points are ironed out and it is possibly to much for
> one GSoC (or maybe to little, who knows). In any case, I think this
> would be a good way to proceed with this work.
>
> I am looking forward to comments or questions from you but also others in
> the LLVM or Polly community.
>
> Cheers,
>   Johannes
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160323/acd04f3e/attachment-0001.html>