<div dir="ltr"><div>(this thread seems to have been split from the original thread in gmail at least - which might make it hard to keep track of the context)<br><br>Ah, it was a different thread: <a href="http://lists.llvm.org/pipermail/llvm-dev/2020-March/139606.html">http://lists.llvm.org/pipermail/llvm-dev/2020-March/139606.html</a> - might be best to pick up from that thread instead of starting a new one.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 17, 2020 at 9:07 PM Nicholas Krause via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <br>
    <br>
    <div>On 3/17/20 6:16 PM, Johannes Doerfert
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="auto">Hey,
        <div dir="auto"><br>
        </div>
        <div dir="auto">Apologies for the wait, everything right now is
          going crazy..</div>
      </div>
    </blockquote>
    Compiler Folks are very busy people as there aren't as much of us
    unfortunately so no need to <br>
    apologize. I've yet to heard from someone on the GCC side and will
    wait until after GCC 11<br>
    is released due to this. Also not to mention the health issues of
    Coronavirus-19.<br>
    <blockquote type="cite">
      <div dir="auto">
        <div dir="auto"><br>
        </div>
        <div dir="auto">I think we should early in move this
          conversation on the llvm Dev list but generally speaking we
          can see three options here:</div>
        <div dir="auto">1) parallelize single passes or a subset of
          passes that are known to not interfer, e.g. the attributor,</div>
        <div dir="auto">2) parallelize analysis pass execution before a
          transformation that needs them,</div>
      </div>
    </blockquote>
    <blockquote type="cite">
      <div dir="auto">3) investigate what needs to be done for a
        parallel execution of many passes, e.g. How can we avoid races
        on shared structure such as the constant pool. </div>
    </blockquote>
    I was researching this on and off for the last few months in terms
    of figuring out how to make the pass manager itself async. Its not
    easy and I'm not even<br>
    sure if that's possible. Not sure about GIMPLE as I would have to
    ask the middle end maintainer on the GCC side but LLVM IR does not
    seem to have shared<br>
    state detection or the core classes and same for the back ends. So
    yes this would interest me. <br>
    <br>
    The first place to start with is which data structures are shared
    for sure. The biggest ones seem to be basic blocks and function
    definitions in terms of shared state, as <br>
    those would be shared by passes running on each function.  We should
    start looking at implementing here locks or ref counting here first
    if your OK with that. <br>
    It also allows me  to understand a little more concrete the linkage
    between the core classes as would be required for multi threading
    LLVM. In addition,<br>
    it allows us to look into partitioning issues with threads at the
    same thing in terms of how to do it.<br></div></blockquote><div><br>As was discussed on the previous thread - generally the assumption is that one wouldn't try to run two function optimizations on the same function at the same time, but, for instance - run function optimizations on unrelated functions at the same time (or CGSCC passes on distinct CGSCCs). But this is difficult in LLVM IR because use lists are shared - so if two functions use the same global variable or call the same 3rd function, optimizing out a function call from each of those functions becomes a write to shared state when trying to update the use list of that 3rd function. MLIR apparently has a different design in this regard that is intended to be more amenable to these situations.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <br>
    If others want to chip it as I've CCed the list, that's fine as well
    and this should be up for discussion with the whole community.<br>
    <br>
    I've given up on the idea of a async pass manager as it seems to
    require IR level detection of changed state between passes but maybe
    I'm wrong,<br>
    <br>
    Nick<br>
    <br>
    <blockquote type="cite">
      <div dir="auto">
        <div dir="auto"><br>
        </div>
        <div dir="auto">What sounds interesting to you?</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Cheers,</div>
        <div dir="auto">  Johannes</div>
        <div dir="auto"><br>
        </div>
        <br>
        <br>
        <div class="gmail_quote" dir="auto">
          <div dir="ltr" class="gmail_attr">On Tue, Mar 17, 2020, 08:09
            Nicholas Krause <<a href="mailto:xerofoify@gmail.com" target="_blank">xerofoify@gmail.com</a>> wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Johanne,<br>
            <br>
            I'm assuming you've been busy as so have I am so I'm pinging
            this email.<br>
            <br>
            Nick<br>
            <br>
            On 3/6/20 7:57 PM, Nicholas Krause wrote:<br>
            > Greetings Johannes,<br>
            ><br>
            > I'm pinging you as you wanted to discuss the ModulePass
            and related <br>
            > infrastructure in terms of<br>
            > making it either multi-threading or preparing for that.
            You stated to <br>
            > wait to this week so now<br>
            > seems a good time.<br>
            ><br>
            ><br>
            > Regards,<br>
            > Nick<br>
            <br>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <br>
  </div>

_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>