<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 21, 2016 at 4:05 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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>
</blockquote><div>Thank you! I would like to have some comments from LLVM developers on how we can extend Loop Vectorizer using a better dependence analysis. Please feel free to share your views.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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>
</blockquote><div>Thats nice of you, Thank you.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  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></blockquote><div>I also think this is the most important step for this project.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  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> Ok.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></blockquote><div>Are you suggesting that such pattern could be a possible client for Polly as an Analysis pass?<br></div><div>I have not thought about them right now, but yes we can include them in the proposal as well.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  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></blockquote><div>I do agree with you here. We need to separate out the interface(API) from LLVM.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  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></blockquote><div>That makes sense. We can fall-back to Polly only when needed.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  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></blockquote><div>I think this will be one of the criteria for a successful implementation of the proposal.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  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></blockquote><div>Yes, possible clients are Loop Vectorizer, Loop Versioning, LNO, etc<br>   <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Cheers,<br>
  Johannes<br>
<span><font color="#888888"><br></font></span></blockquote><div>Thank you for your suggestions. Looking forward for more comments from the LLVM and Polly community.<br></div><div><br>Regards,<br></div><div>Utpal Bora <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><font color="#888888">
--<br>
You received this message because you are subscribed to the Google Groups "Polly Development" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:polly-dev%2Bunsubscribe@googlegroups.com" target="_blank">polly-dev+unsubscribe@googlegroups.com</a>.<br>
For more options, visit <a href="https://groups.google.com/d/optout" rel="noreferrer" target="_blank">https://groups.google.com/d/optout</a>.<br>
</font></span></blockquote></div><br></div></div>