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

Johannes Doerfert via llvm-dev llvm-dev at lists.llvm.org
Thu Mar 24 02:05:09 PDT 2016


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 ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: Digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160324/72ccf5ef/attachment.sig>


More information about the llvm-dev mailing list