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

[Utpal Bora via llvm-dev]

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/fa8b55b9/attachment.html>