<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>On 01/13/2017 12:11 PM, Mehdi Amini wrote:<br>
    </p>
    <blockquote
      cite="mid:72AD9CA2-1C0F-404E-A358-E293C42EE1A2@apple.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <br class="">
      <div>
        <blockquote type="cite" class="">
          <div class="">On Jan 13, 2017, at 9:41 AM, Hal Finkel <<a
              moz-do-not-send="true" href="mailto:hfinkel@anl.gov"
              class="">hfinkel@anl.gov</a>> wrote:</div>
          <br class="Apple-interchange-newline">
          <div class="">
            <div bgcolor="#FFFFFF" text="#000000" class="">
              <p class=""><br class="">
              </p>
              <div class="moz-cite-prefix">On 01/13/2017 12:29 AM, Mehdi
                Amini wrote:<br class="">
              </div>
              <blockquote
                cite="mid:5ADA0551-E374-48A7-8311-005E3AA947E4@apple.com"
                type="cite" class=""> <br class="">
                <div class="">
                  <blockquote type="cite" class="">
                    <div class="">On Jan 12, 2017, at 5:02 PM, Hal
                      Finkel <<a moz-do-not-send="true"
                        href="mailto:hfinkel@anl.gov" class="">hfinkel@anl.gov</a>>
                      wrote:</div>
                    <div class="">
                      <div bgcolor="#FFFFFF" text="#000000" class="">
                        <p class="">On 01/12/2017 06:20 PM, Reid
                          Kleckner via llvm-dev wrote:</p>
                        <blockquote
cite="mid:CACs=tyKWmdPAQGJkJdrF9xdov-TnV02ofpPURjMGo7rwo28V8w@mail.gmail.com"
                          type="cite" class="">
                          <div dir="ltr" class="">
                            <div class="gmail_extra">
                              <div class="gmail_quote">On Wed, Jan 11,
                                2017 at 8:13 PM, Mehdi Amini <span
                                  dir="ltr" class=""><<a
                                    moz-do-not-send="true"
                                    href="mailto:mehdi.amini@apple.com"
                                    target="_blank" class="">mehdi.amini@apple.com</a>></span>
                                wrote:
                                <blockquote class="gmail_quote"
                                  style="margin:0 0 0
                                  .8ex;border-left:1px #ccc
                                  solid;padding-left:1ex">
                                  <div style="word-wrap:break-word"
                                    class="">
                                    <div class="">
                                      <div class="">Can you elaborate
                                        why? I’m curious.</div>
                                    </div>
                                  </div>
                                </blockquote>
                                <div class=""><br class="">
                                </div>
                                <div class="">The con of proposal c was
                                  that many passes would need to learn
                                  about many region intrinsics. With
                                  tokens, you only need to teach all
                                  passes about tokens, which they should
                                  already know about because WinEH and
                                  other things use them.</div>
                                <div class=""><br class="">
                                </div>
                                <div class="">With tokens, we can add as
                                  many region-introducing intrinsics as
                                  makes sense without any additional
                                  cost to the middle end. We don't need
                                  to make one omnibus region intrinsic
                                  set that describes every parallel loop
                                  annotation scheme supported by LLVM.
                                  Instead we would factor things
                                  according to other software design
                                  considerations.</div>
                              </div>
                            </div>
                          </div>
                        </blockquote>
                        <br class="">
                        I think that, unless we allow frontends to add
                        their own intrinsics without recompiling LLVM,
                        this severely restricts the usefulness of this
                        feature.</div>
                    </div>
                  </blockquote>
                  <div class=""><br class="">
                  </div>
                  <div class="">I’m not convinced that “building a
                    frontend without recompiling LLVM while injecting
                    custom passes” is a strong compelling use-case, i.e.
                    can you explain why requiring such
                    use-case/frontends to rebuild LLVM is so limiting?</div>
                </div>
              </blockquote>
              <br class="">
              I don't understand your viewpoint. Many frontends either
              compose their own pass pipelines or use the existing
              extension-point mechanism. Some frontends, Chapel for
              example, can insert code using custom address spaces and
              then insert passes later to turn accesses using pointers
              to those address spaces into runtime calls. This is the
              kind of design we'd like to support, without forcing
              frontends to use custom versions of LLVM, but with
              annotated regions instead of just with address spaces.<br
                class="">
            </div>
          </div>
        </blockquote>
        <div><br class="">
        </div>
        <div>I think we’re talking about two different things here: you
          mentioned originally “without recompiling LLVM”, which I don’t
          see as major blocker, while now you’re now clarifying I think
          that you’re more concerned about putting a requirement on a
          *custom* LLVM, as in “it wouldn’t work with the source from a
          vanilla upstream LLVM”, which I agree is a different story.</div>
        <div><br class="">
        </div>
        <div>That said, it extends the point from the other email (in
          parallel) about the semantics of the intrinsics: while your
          solution allows these frontend to reuse the intrinsics, it
          means that upstream optimization have to consider such
          intrinsics as optimization barrier because their semantic is
          unknown.</div>
      </div>
    </blockquote>
    <br>
    I see no reason why this needs to be true (at least so long as
    you're willing to accept a certain amount of "as if" parallelism).
    Moreover, if it is true, then we'll lose the benefits of, for
    example, being able to hoist scalar loads out of parallel loops. We
    might need to include dependencies on "inaccessible memory", so
    cover natural runtime dependencies by default (this can be refined
    with custom AA logic), but that is not a complete code-motion
    barrier. Memory being explicitly managed will end up as arguments to
    the region intrinsics, so we'll automatically get more-fine-grained
    information.<br>
    <br>
     -Hal<br>
    <br>
    <blockquote
      cite="mid:72AD9CA2-1C0F-404E-A358-E293C42EE1A2@apple.com"
      type="cite">
      <div>
        <div><br class="">
        </div>
        <div><br class="">
        </div>
        <div>— </div>
        <div>Mehdi</div>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
  </body>
</html>