[llvm-dev] [RFC] Polly Status and Integration

[C Bergström via llvm-dev]

On Fri, Sep 15, 2017 at 12:04 PM, Hal Finkel <hfinkel at anl.gov> wrote:

>
> On 09/13/2017 07:30 AM, C Bergström wrote:
>
>
> On Wed, Sep 13, 2017 at 8:05 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>
>>
>> On 09/13/2017 06:53 AM, C Bergström wrote:
>>
>>
>>
>> On Wed, Sep 13, 2017 at 7:43 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>>
>>>
>>> On 09/13/2017 02:16 AM, C Bergström wrote:
>>>
>>> A completely non-technical point, but what's the current "polly"
>>> license? Does integrating that code conflict in any way with the work being
>>> done to relicense llvm?
>>>
>>>
>>> Good question. I discussed this explicitly with Tobias, and his general
>>> feeling is that relicensing isl again would be doable if necessary (we
>>> already did this once, to an MIT license, in order to enable better LLVM
>>> integration).
>>>
>>>
>>> Does adding polly expose any additional legal risks? Some people from
>>> Reservoir labs have explicitly stated to me that some of their patents
>>> target polyhedral optimizations. You should almost certainly review their
>>> portfolio or contact them.
>>>
>>> If at some point someone wants to add real loop optimizations - will
>>> there be a conflict?
>>>
>>>
>>> Can you define "real loop optimizations"?
>>>
>>
>> I think most readers here will understand what I mean. I can go find
>> specific chapters of textbooks if it's unclear. Maybe the word "real" could
>> be replaced with traditional, well tested, industry standard or something
>> else. (ok I'll stop being snarky)
>>
>>
>> That's what I thought you meant. No, I believe there's not a conflict. In
>> fact, this will provide infrastructure to make this easier. While you can
>> handle a bunch of these as one problem using this kind of framework, you
>> don't need to do so.
>>
>
>
> By this I think you either mean A) the polly stuff will provide a better
> analysis pass or B) the llvm side will have a better analysis pass, correct?
>
> If you mean A, then that's cool. I was unaware that poly had an interface
> and could be used like this.
>
>
> It does now (I believe that it was developed as part of a GSoC project
> last year: http://llvm.org/svn/llvm-project/polly/trunk/include/
> polly/DependenceInfo.h).
>
> The cost model aspect is very important. I'm mildly curious how it builds
> this.
>
> (correct me if I'm wrong please) It's my lay understanding that poly
> optimizations are an either or and do not generally play well with
> tradtional methods. More specifically, after poly things are "messed up"
> and it would be difficult to do another (traditional type) transformation
> that it missed.
>
>
> Polly doesn't really use this currently, but isl has an incremental
> scheduling interface, and other ways to guide the transformation process,
> so it should be possible to build passes that use the infrastructure to do
> a restricted subset of transformations. In short, it can do a bunch of
> stuff at the same time, but doesn't have to be used that way. As such, you
> can actually use Polly's infrastructure to build many of these individual
> classical transformations (in what I believe is a relatively-simply way -
> although take this with a grain of salt because I don't know how much this
> has been tried in practice).
>

Thanks for your replies.

I remember talking with a researcher, I can't remember who, but one of the
side effect upsides to this may be that "loop transformations" end up being
handled in a way that's closer to optimal. Most compilers, at least the
ones I have worked on, will perform loop optimizations and analysis on a
whole PU or TU. By feeding polly smaller pieces (regions?) you'll allow it
to do a more accurate job as well as not have hueristics which are good for
loop, but bad for maybe some other scalar code impacted. The closest
work-around I have to this was outlining the region/kernel into it's own
PU, doing everthing needed and then very late in the compilation phase
"inlining" it again.

I'm curious how this all turns out..

good luck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170915/ba2da37d/attachment.html>