<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 13, 2017 at 8:05 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span>
<p><br>
</p>
<div class="m_-459361835952577216m_-2802422639224529799moz-cite-prefix">On 09/13/2017 06:53 AM, C Bergström
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Sep 13, 2017 at 7:43 PM, Hal
Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span>
<p><br>
</p>
<div class="m_-459361835952577216m_-2802422639224529799m_-268822120178151296moz-cite-prefix">On
09/13/2017 02:16 AM, C Bergström wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>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?<br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</span> 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).<span><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div><br>
</div>
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.<br>
<br>
</div>
If at some point someone wants to add real
loop optimizations - will there be a
conflict?<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</span> Can you define "real loop optimizations"?<span><br>
</span></div>
</blockquote>
<div><br>
</div>
<div>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)<br>
</div>
</div>
</div>
</div>
</blockquote>
<br></span>
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.<span><br></span></div></blockquote><div><br><br></div><div>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?<br><br></div><div>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.<br></div><div><br></div><div>(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.<br><br><br></div></div></div></div>