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

[Utpal Bora via llvm-dev]

Hi Johannes,

This is interesting. I will include a block diagram in the proposal. Thanks
a lot.

Regards,

Utpal Bora
Ph.D. Scholar
+917032002001
Computer Science & Engineering
IIT Hyderabad


On Thu, Mar 24, 2016 at 2:35 PM, Johannes Doerfert <
doerfert at cs.uni-saarland.de> wrote:

> On 03/23, Hongbin Zheng wrote:
> > Hi Johannes,
> >
> > On Mon, Mar 21, 2016 at 6:35 PM, Johannes Doerfert <
> > doerfert at cs.uni-saarland.de> wrote:
> >
> > > 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.]
> > >
> > 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.
> Totally agreed. Some kind of ScopBuilder interface that can be queried
> would be perfect. Additionally a DependenceBuilder.
>
> I would imagine something along the lines of:
>
>
>    Passes:   ScopInfo <-----------[depends]----------- DependenceInfo
>                  |                                              |
>              [queries]                                      [queries]
>                  |                                              |
>                  V                                              V
> Interface:  ScopBuilder                          ------ DependenceBuilder
>               A  |                               |              |       A
>               |  |                               |          [creates]   |
>               |  |                               |              |       |
>               |  |                               |              V       |
>   Objects:    |  |--[creates]--> Scop <--[uses]--|         Dependences  |
>               |                    |                            |       |
>               |-----[queries]--|   |-----[uses]--| |---[uses]---|       |
>                                |                 V V                    |
> New Pass/Interface:            |----------- PolyhedralInfo --[queries]--|
>                                                   A
>                                                   |
>                                                   |
>                                       [non-polyhedral queries]
>                                                   |
>                                                   |
>                                            **LLVM Passes**
>
> > For 1), can we always construct a whole function Scop (excluding the
> entry
> > block which contains allocas)?
> We could even with allocas ;)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Polly Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to polly-dev+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160324/79579447/attachment.html>