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

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)

I really do appreciate your feedback and I do think something beyond just a
soft discussion is required on the IP/license vetting. The relicense
process used before should be substantially similar to the process which
LLVM is going to use. There's a big difference between someone randomly
changing a license header and nobody complaining vs getting explicit and
signed agreements from all copyright holders.

Further, my reading on some of the patents causes significant concerns. (A
point everyone will want to ignore until it's too late). I'm avoiding
exact
references, but soon I'll start I'll start listing exact patents if
nobody
else cares.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170913/24142313/attachment.html>

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 
> <mailto: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.
>
> I really do appreciate your feedback and I do think something beyond 
> just a soft discussion is required on the IP/license vetting. The 
> relicense process used before should be substantially similar to the 
> process which LLVM is going to use. There's a big difference between 
> someone randomly changing a license header and nobody complaining vs 
> getting explicit and signed agreements from all copyright holders.
The LLVM Foundation has a good lawyer advising on the relicensing 
process. No one is taking this lightly.
>
> Further, my reading on some of the patents causes significant 
> concerns. (A point everyone will want to ignore until it's too late). 
> I'm avoiding exact references, but soon I'll start I'll start
listing
> exact patents if nobody else cares.
>
Please raise IP concerns with the LLVM Foundation board of directors 
(board at llvm.org). We don't discuss specific IP issues on this list.

Thanks again,
Hal
>
>
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170913/911ff4bf/attachment.html>

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. 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. Since llvm doesn't have or doesn't do the traditional
side
very well, this is less a concern though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170913/f39f09e4/attachment.html>