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

[Hongbin Zheng via llvm-dev]

Hi Utpal,

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.

Thanks
Hongbin

On Fri, Mar 25, 2016 at 4:07 PM, Utpal Bora <cs14mtech11017 at iith.ac.in>
wrote:

> Hi ether,
>
> Your suggestion is appropriate with respect to LLVM framework.
> However, I am not aware of such a common interface for Dependence Analysis
> as there is one for AliasAnalysis.
> 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.
> The integration will not be tight as we can return empty analysis result
> if Polly is not compiled with LLVM tools.
>
>
> Regards,
>
> Utpal Bora
> Ph.D. Scholar
> +917032002001
> Computer Science & Engineering
> IIT Hyderabad
>
>
> On Fri, Mar 25, 2016 at 7:53 AM, Hongbin Zheng <etherzhhb at gmail.com>
> wrote:
>
>> In the design the LLVM passes always directly communicate with PolyhedralInfo,
>> this requires Polly tightly integrate in to LLVM.
>>
>> If we do not want a tight integration, we can do the following:
>> 1. Introduce an abstract memory dependency query interface, like
>> AliasAnalysis
>> 2. I remember LLVM had already have dependency analysis, this can be the
>> default implementation of the memory dependency query interface. Or the
>> default implementation can be a "may depend" analysis.
>> 3. PolyhedralInfo is yet another implementation of memory dependency
>>  analysis.
>>
>> That is:
>>
>> LLVM Passes --> DependencyAnalysis ---> Default implementation
>>                                                            \
>>                                                             \---->
>> Implementation in LLVM
>>                                                              \
>>                                                               ----> Polyhedral
>> dependency analysis in Polly
>>
>>
>>
>> On Thu, Mar 24, 2016 at 5:05 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 ;)
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160325/d332de88/attachment.html>