<div dir="ltr"><div>Hi Johannes,<br><br></div>This is interesting. I will include a block diagram in the proposal. Thanks a lot.<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><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>+917032002001<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><div class="gmail_quote">On Thu, Mar 24, 2016 at 2: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"><div class="HOEnZb"><div class="h5">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">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 class=""><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>
<div class="HOEnZb"><div class="h5"><br>
--<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">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>
</div></div></blockquote></div><br></div>