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

[Johannes Doerfert via llvm-dev]

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.]
  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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: Digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/81c2976a/attachment.sig>