<div dir="ltr">Hi Utpal,<div><br></div><div>Yes, we do not need to drive ourself crazy and do everything in this GSoC. We can build a tight integration in GSoC and improve later when necessary.</div><div><br></div><div>Thanks</div><div>Hongbin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 25, 2016 at 4:07 PM, Utpal Bora <span dir="ltr"><<a href="mailto:cs14mtech11017@iith.ac.in" target="_blank">cs14mtech11017@iith.ac.in</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi ether,<br><br></div><div>Your suggestion is appropriate with respect to LLVM framework.<br></div><div>However, I am not aware of such a common interface for Dependence Analysis as there is one for AliasAnalysis.<br></div>The current plan is to provide the new Dependence Analysis interface that can be used when the other analysis engines fail to provide a concrete result. I do not want to overestimate things by proposing such a common framework for Dependence analysis in LLVM. <br></div>The integration will not be tight as we can return empty analysis result if Polly is not compiled with LLVM tools.<br><div><br></div></div><div class="gmail_extra"><span class=""><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div>Regards,<br><br></div>Utpal Bora<br></div><div>Ph.D. Scholar<br><a href="tel:%2B917032002001" value="+917032002001" target="_blank">+917032002001</a><br></div>Computer Science & Engineering<br></div><div>IIT Hyderabad<br></div><div dir="ltr"><br></div></div></div></div></div></div></div></div></div></div></div>
<br></span><div><div class="h5"><div class="gmail_quote">On Fri, Mar 25, 2016 at 7:53 AM, Hongbin Zheng <span dir="ltr"><<a href="mailto:etherzhhb@gmail.com" target="_blank">etherzhhb@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">In the design the LLVM passes always directly communicate with <span style="font-size:12.8px">PolyhedralInfo, this requires Polly tightly integrate in to LLVM.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">If we do not want a tight integration, we can do the following:</span></div><div><span style="font-size:12.8px">1. Introduce an abstract memory dependency query interface, like AliasAnalysis</span></div><div><span style="font-size:12.8px">2. I remember LLVM had already have dependency analysis, this can be the default implementation of the </span><span style="font-size:12.8px">memory dependency query interface. Or the default implementation can be a "may depend" analysis.</span></div><div><span style="font-size:12.8px">3. </span><span style="font-size:12.8px">PolyhedralInfo</span><span style="font-size:12.8px"> is yet another implementation of </span><span style="font-size:12.8px">memory dependency</span><span style="font-size:12.8px"> analysis.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">That is:</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">LLVM Passes --> DependencyAnalysis ---> Default implementation</span></div><div><span style="font-size:12.8px"> \</span></div><div><span style="font-size:12.8px"> \----> Implementation in LLVM</span></div><div><span style="font-size:12.8px"> \</span></div><div><span style="font-size:12.8px"> ----> </span><span style="font-size:12.8px">Polyhedral dependency analysis in Polly</span></div><div><br></div><div><span style="font-size:12.8px"><br></span></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 24, 2016 at 5: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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On 03/23, Hongbin Zheng wrote:<br>
> Hi Johannes,<br>
><br>
> On Mon, Mar 21, 2016 at 6:35 PM, Johannes Doerfert <<br>
> <a href="mailto:doerfert@cs.uni-saarland.de" target="_blank">doerfert@cs.uni-saarland.de</a>> wrote:<br>
><br>
> > 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>
> ><br>
> I really like this direction. In general, we may want to decouple the<br>
> ScopDetection/ScopInfo construction logic from the pass logic, such that we<br>
> can run the logic ScopDetection and ScopInfo construction in a function<br>
> pass, call graph scc pass, or even a loop pass.<br>
</div></div>Totally agreed. Some kind of ScopBuilder interface that can be queried<br>
would be perfect. Additionally a DependenceBuilder.<br>
<br>
I would imagine something along the lines of:<br>
<br>
<br>
Passes: ScopInfo <-----------[depends]----------- DependenceInfo<br>
| |<br>
[queries] [queries]<br>
| |<br>
V V<br>
Interface: ScopBuilder ------ DependenceBuilder<br>
A | | | A<br>
| | | [creates] |<br>
| | | | |<br>
| | | V |<br>
Objects: | |--[creates]--> Scop <--[uses]--| Dependences |<br>
| | | |<br>
|-----[queries]--| |-----[uses]--| |---[uses]---| |<br>
| V V |<br>
New Pass/Interface: |----------- PolyhedralInfo --[queries]--|<br>
A<br>
|<br>
|<br>
[non-polyhedral queries]<br>
|<br>
|<br>
**LLVM Passes**<br>
<span><br>
> For 1), can we always construct a whole function Scop (excluding the entry<br>
> block which contains allocas)?<br>
</span>We could even with allocas ;)<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div>