<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 15, 2017 at 12:04 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 class="">
    <p><br>
    </p>
    <div class="m_2870096389523980445moz-cite-prefix">On 09/13/2017 07:30 AM, C Bergström
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <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_2870096389523980445m_-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_2870096389523980445m_-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.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    It does now (I believe that it was developed as part of a GSoC
    project last year:
<a class="m_2870096389523980445moz-txt-link-freetext" href="http://llvm.org/svn/llvm-project/polly/trunk/include/polly/DependenceInfo.h" target="_blank">http://llvm.org/svn/llvm-<wbr>project/polly/trunk/include/<wbr>polly/DependenceInfo.h</a>).
    <br><span class="">
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div> 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.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    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).<span class="HOEnZb"><font color="#888888"><br></font></span></div></blockquote><div><br></div>Thanks for your replies.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">I'm curious how this all turns out..</div><div class="gmail_quote"><br></div><div class="gmail_quote">good luck<br></div></div></div>