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

[Tobias Grosser via llvm-dev]

On Wed, Sep 13, 2017, at 13:43, Hal Finkel 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).

Right. isl was relicensed to MIT following an advice from Chris Lattner.
We got written consent from all contributors and copyright owners. If
need arises -- we can look into this as part of the LLVM relicensing
process -- with even better legal advice.

> > 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"?
> 
> >
> > What's the DWARF look like after poly transformations?
> 
> Right now, Polly essentially changes loop structures around existing 
> basic blocks (so the debug info on the loop bodies should be okay). Like 
> most of our other loop optimizations, induction variables don't fare 
> very well (an area where improvement is generally needed).

Right. 

> > The talk about performance is pretty light - It would be good to get 
> > something besides just a handful of spotlight known codes. Also code 
> > size, compilation speed. etc
> 
> This is a good point, and more information should definitely be provided 
> in this regard. The larger question, from my perspective, is will the 
> infrastructure significantly help us get from where we are to where we 
> want to be?
> 
> > ------------
> > flag bikeshed - If it's not ready for -O3 - create specific flags to 
> > specific poly passes. Creating yet another micro flag like -O3poly 
> > just doesn't make sense to me. (keep it simple.) When it's really 
> > really ready, enable it with the rest of the loop heavy passes.
> >
> 
> Regarding transformations, this is also my preference. We'll reach a 
> much smaller audience if special flags are required. There are also two 
> aspects of "ready" here: it might be ready as an analysis infrastructure 
> well before we can enable loop restructuring by default.

Sure, that's the ultimate goal and clearly something we should shoot for
"soon".

Best,
Tobias