<div dir="ltr">Hi Johannes,<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 21, 2016 at 6:35 PM, Johannes Doerfert <span dir="ltr"><<a href="mailto:doerfert@cs.uni-saarland.de" target="_blank">doerfert@cs.uni-saarland.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Utpal,<br>
<br>
First of, I think you made nice process here and have some very good<br>
ideas of what we could do in the future.<br>
<br>
[NOTE: I CC'ed some people that have shown interest in this topic but I<br>
might have forgotten some, therefor I also added the llvm-dev list.]<br>
<br>
For the upcoming GSoC proposal we should slow down a little bit and<br>
reevaluate our goals. After talking to a couple of LLVM and Polly folks<br>
at EuroLLVM last week, I hope to have a fairly good idea of how to<br>
proceed. To this end, I will give you my personal road map that might be<br>
a good start for the proposal too, though it is not the only way we<br>
could do this:<br>
<br>
  1) Make ScopInfo & DependenceInfo function passes to avoid the<br>
     RegionPassManager for these Polly analysis parts. [This doesn't<br>
     need to be the first step but it should be done at some point.]<br>
  2) Create a secondary ScopDetection & ScopInfo that is restricted to<br>
     analyze a single loop. We might just create a dummy region for this<br>
     loop and use the original ScopDetection & ScopInfo. The goal is to<br>
     make (this secondary) ScopDetection & ScopInfo demand driven and<br>
     non-dependent on the RegionInfo analysis. [Same as before, this<br>
     does not need to happen right away.]<br></blockquote><div>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.</div><div><br></div><div>For 1), can we always construct a whole function Scop (excluding the entry block which contains allocas)?</div><div><br></div><div>Thanks</div><div>Hongbin</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  3) Scan the LLVM source code for uses of ScalarEvolution or reasoning<br>
     about the execution of basic blocks [this includes thing like loop<br>
     trip count queries]. These are possible candidates that might<br>
     profit from the knowledge contained in a "Scop" object.<br>
  4) Start an API that translates (simple) queries from the LLVM passes<br>
     to lookups in a Scop. The LLVM pass should never "see" the Scop<br>
     object or anything related for that matter. It will only require a<br>
     "PolyhedralInfo" pass and query it.<br>
  5) Use the above API to augment the information available at the<br>
     points identified in 3), but only if the available information is<br>
     not sufficient to apply the intended transformation.<br>
  6) Evaluate the impact on compile and runtime for each pass that was<br>
     augmented. Check how often (and for which kind of codes) the<br>
     polyhedral information was queried and how often it allowed a<br>
     transformation.<br>
  7) Go back to 3 but now look for passes/opportunities that would need<br>
     dependence information, thus the DependenceInfo pass. Then proceed<br>
     with 4), 5) and 6) for dependences.<br>
<br>
Note that not all points are ironed out and it is possibly to much for<br>
one GSoC (or maybe to little, who knows). In any case, I think this<br>
would be a good way to proceed with this work.<br>
<br>
I am looking forward to comments or questions from you but also others in<br>
the LLVM or Polly community.<br>
<br>
Cheers,<br>
  Johannes<br>
</blockquote></div><br></div></div>