[llvm-dev] [RFC] Polly Status and Integration (original) (raw)

Tobias Grosser via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 13 05:26:55 PDT 2017

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

More information about the llvm-dev mailing list