On 2/28/20 12:19 AM, Chris Lattner wrote:> Hi Nicholas, > > You might want to check out MLIR: its pass manager is already automatically and implicitly multithreaded. > > -ChrisChris, I was aware that LLVM was moving to MLIR at some point due to this. I've curious as to how MLIR deals with IPO as that's the problem I was running into. Even if you have pipelines what guarantees do we have about IPO or are there any. For example if an analysis pass runs after a loop pass for heuristics to get good data, does MLIR ensure that? The problem isn't getting a pipeline as much as IPO issues in terms of rescheduling in a pipeline or incorrectly splitting up into pipelines. I yet to find a good solution on the GCC side as well and it seems that there will be issues with this no matter what, not sure of what trade offs the LLVM side is willing to make. The other issues is that graph data structures to my knowledge do not allow insertion of multiple nodes at the same time or how to scale the graphs for callers or SSA. Not sure if you guys have encapsulated the operators and data structures in a series of classes as that would be the first part. The other part is figuring out how to link and interact with build systems to launch threads from make -j or other similar things. Thanks for the notice about MLIR through maybe my IPO is not really there but after reading parts of it seems to be a issue through a little smaller still and thanks for the prompt response, Nick>> On Feb 27, 2020, at 7:05 PM, Nicholas Krause via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Greetings All, >> >> For the last few months since the GCC Cauldron I've been researching/helping out >> plan for multi-threading GCC. I've posted my GCC ideas here: >> https://docs.google.com/document/d/1po_RRgSCtRyYgMHjV0itW8iOzJXpTdHYIpC9gUMjOxk/edit >> >> as I've heard there is interest on the LLVM side as well. I've talked to some of the IBM folks from >> the Toronto area about it face to face due to them having more middle end and back end knowledge >> then me. >> >> Not sure if anyone is interested in my ideas or wants me to extend my help on the LLVM side, >> >> Nick >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
On Feb 27, 2020, at 9:44 PM, Nicholas Krause <xerofoify at gmail.com> wrote:> On 2/28/20 12:19 AM, Chris Lattner wrote: >> Hi Nicholas, >> >> You might want to check out MLIR: its pass manager is already automatically and implicitly multithreaded. >> >> -Chris > Chris, > > I was aware that LLVM was moving to MLIR at some point due to this. I've curious as > to how MLIR deals with IPO as that's the problem I was running into. Even if you have > pipelines what guarantees do we have about IPO or are there any. For example if an > analysis pass runs after a loop pass for heuristics to get good data, does MLIR ensure > that? The problem isn't getting a pipeline as much as IPO issues in terms of rescheduling > in a pipeline or incorrectly splitting up into pipelines. I yet to find a good solution on the > GCC side as well and it seems that there will be issues with this no matter what, not > sure of what trade offs the LLVM side is willing to make.Hi Nicholas, It is very difficult to mix things like loop passes and IPO passes in any system, unless one is prepared to preserve the analysis results that the other depend on. One nice thing about MLIR is that it defines this away, by allowing explicit representation of loops in the IR. This means that it isn’t an analysis pass that gets “invalidated” like the existing LLVM LoopInfo analysis pass. It is just structurally impossible for this to happen. I don’t think that all of the AnalysisPass’s in LLVM have been super successful.> The other issues is that graph data structures to my knowledge do not allow insertion > of multiple nodes at the same time or how to scale the graphs for callers or SSA. Not > sure if you guys have encapsulated the operators and data structures in a series of > classes as that would be the first part. The other part is figuring out how to link and > interact with build systems to launch threads from make -j or other similar things.Yeah, MLIR handles that by factoring global use-def chains on symbols (e.g. functions) as being different than local use-def chains. This makes it much more efficient. You can find more information on MLIR symbols here <https://mlir.llvm.org/docs/SymbolsAndSymbolTables/>.> Thanks for the notice about MLIR through maybe my IPO is not really there > but after reading parts of it seems to be a issue through a little smaller still > and thanks for the prompt response,Sure, happy to help. It would be great to see a GIMPLE dialect in MLIR someday :-) -Chris> > Nick >>> On Feb 27, 2020, at 7:05 PM, Nicholas Krause via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> Greetings All, >>> >>> For the last few months since the GCC Cauldron I've been researching/helping out >>> plan for multi-threading GCC. I've posted my GCC ideas here: >>> https://docs.google.com/document/d/1po_RRgSCtRyYgMHjV0itW8iOzJXpTdHYIpC9gUMjOxk/edit >>> >>> as I've heard there is interest on the LLVM side as well. I've talked to some of the IBM folks from >>> the Toronto area about it face to face due to them having more middle end and back end knowledge >>> then me. >>> >>> Not sure if anyone is interested in my ideas or wants me to extend my help on the LLVM side, >>> >>> Nick >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200227/7604cdb7/attachment.html>
On 2/28/20 12:56 AM, Chris Lattner wrote:> On Feb 27, 2020, at 9:44 PM, Nicholas Krause <xerofoify at gmail.com > <mailto:xerofoify at gmail.com>> wrote: >> On 2/28/20 12:19 AM, Chris Lattner wrote: >>> Hi Nicholas, >>> >>> You might want to check out MLIR: its pass manager is already >>> automatically and implicitly multithreaded. >>> >>> -Chris >> Chris, >> >> I was aware that LLVM was moving to MLIR at some point due to this. >> I've curious as >> to how MLIR deals with IPO as that's the problem I was running into. >> Even if you have >> pipelines what guarantees do we have about IPO or are there any. For >> example if an >> analysis pass runs after a loop pass for heuristics to get good >> data, does MLIR ensure >> that? The problem isn't getting a pipeline as much as IPO issues in >> terms of rescheduling >> in a pipeline or incorrectly splitting up into pipelines. I yet to >> find a good solution on the >> GCC side as well and it seems that there will be issues with this no >> matter what, not >> sure of what trade offs the LLVM side is willing to make. > > Hi Nicholas, > > It is very difficult to mix things like loop passes and IPO passes in > any system, unless one is prepared to preserve the analysis results > that the other depend on. One nice thing about MLIR is that it > defines this away, by allowing explicit representation of loops in the > IR. This means that it isn’t an analysis pass that gets “invalidated” > like the existing LLVM LoopInfo analysis pass. It is just > structurally impossible for this to happen. I don’t think that all of > the AnalysisPass’s in LLVM have been super successful. > >> The other issues is that graph data structures to my knowledge do not >> allow insertion >> of multiple nodes at the same time or how to scale the graphs for >> callers or SSA. Not >> sure if you guys have encapsulated the operators and data structures >> in a series of >> classes as that would be the first part. The other part is figuring >> out how to link and >> interact with build systems to launch threads from make -j or other >> similar things. > > Yeah, MLIR handles that by factoring global use-def chains on symbols > (e.g. functions) as being different than local use-def chains. This > makes it much more efficient. You can find more information on MLIR > symbols here <https://mlir.llvm.org/docs/SymbolsAndSymbolTables/>. > >> Thanks for the notice about MLIR through maybe my IPO is not really there >> but after reading parts of it seems to be a issue through a little >> smaller still >> and thanks for the prompt response, > > Sure, happy to help. It would be great to see a GIMPLE dialect in > MLIR someday :-) > > -ChrisChris, I asked the GCC what they want to do about MLIR and am waiting for a reply. Anyhow what is the status and what parts are we planning to move to MLIR in LLVM/Clang. I've not seen any discussion on that other than starting to plan for it. Perhaps we should start a wiki page for that as I don't think all parts need to be MLIR. I don't have access to writing for the wiki so unfortunately I can't start writing it up unless I get access. Regards and this is one reason you do your research before writing a multi-threading program a lot of the research or work has been done at this point, Nick> >> >> Nick >>>> On Feb 27, 2020, at 7:05 PM, Nicholas Krause via llvm-dev >>>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>>> >>>> Greetings All, >>>> >>>> For the last few months since the GCC Cauldron I've been >>>> researching/helping out >>>> plan for multi-threading GCC. I've posted my GCC ideas here: >>>> https://docs.google.com/document/d/1po_RRgSCtRyYgMHjV0itW8iOzJXpTdHYIpC9gUMjOxk/edit >>>> >>>> as I've heard there is interest on the LLVM side as well. I've >>>> talked to some of the IBM folks from >>>> the Toronto area about it face to face due to them having more >>>> middle end and back end knowledge >>>> then me. >>>> >>>> Not sure if anyone is interested in my ideas or wants me to extend >>>> my help on the LLVM side, >>>> >>>> Nick >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200228/a50b3cb3/attachment.html>
+Chandler & Alina for new pass manager context On Thu, Feb 27, 2020 at 9:45 PM Nicholas Krause via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > > On 2/28/20 12:19 AM, Chris Lattner wrote: > > Hi Nicholas, > > > > You might want to check out MLIR: its pass manager is already > automatically and implicitly multithreaded. > > > > -Chris > Chris, > > I was aware that LLVM was moving to MLIR at some point due to this.FWIW: I don't /tihnk/ that's quite an accurate representation of the situation. MLIR is now part of the LLVM project, but so far I haven't seen any discussions of moving the core LLVM project itself to MLIR (admittedly I'm not super clear on the details of MLIR or what that'd look like - I would've guessed that LLVM would itself be a lower level that a given MLIR stack might lower to, etc). There's been some discussion of folks interested in experimenting with using MLIR in Clang, though that's not a project goal right now.> I've > curious as > to how MLIR deals with IPO as that's the problem I was running into. >FWIW I believe LLVM's new pass manager (NPM) was designed with parallelism and the ability to support this situation (that MLIR doesn't? Or doesn't to the degree/way in which the NPM does). I'll leave it to folks (Chandler probably has the most context here) to provide some more detail there if they can/have time.> Even if you have > pipelines what guarantees do we have about IPO or are there any. For > example if an > analysis pass runs after a loop pass for heuristics to get good data, > does MLIR ensure > that? The problem isn't getting a pipeline as much as IPO issues in > terms of rescheduling > in a pipeline or incorrectly splitting up into pipelines. I yet to find > a good solution on the > GCC side as well and it seems that there will be issues with this no > matter what, not > sure of what trade offs the LLVM side is willing to make. > > The other issues is that graph data structures to my knowledge do not > allow insertion > of multiple nodes at the same time or how to scale the graphs for > callers or SSA. Not > sure if you guys have encapsulated the operators and data structures in > a series of > classes as that would be the first part. The other part is figuring out > how to link and > interact with build systems to launch threads from make -j or other > similar things. > > > Thanks for the notice about MLIR through maybe my IPO is not really there > but after reading parts of it seems to be a issue through a little > smaller still > and thanks for the prompt response, > > Nick > >> On Feb 27, 2020, at 7:05 PM, Nicholas Krause via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> > >> Greetings All, > >> > >> For the last few months since the GCC Cauldron I've been > researching/helping out > >> plan for multi-threading GCC. I've posted my GCC ideas here: > >> > https://docs.google.com/document/d/1po_RRgSCtRyYgMHjV0itW8iOzJXpTdHYIpC9gUMjOxk/edit > >> > >> as I've heard there is interest on the LLVM side as well. I've talked > to some of the IBM folks from > >> the Toronto area about it face to face due to them having more middle > end and back end knowledge > >> then me. > >> > >> Not sure if anyone is interested in my ideas or wants me to extend my > help on the LLVM side, > >> > >> Nick > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200229/63f03ca7/attachment.html>
On Feb 29, 2020, at 2:08 PM, David Blaikie <dblaikie at gmail.com> wrote:> I've > curious as > to how MLIR deals with IPO as that's the problem I was running into. > > FWIW I believe LLVM's new pass manager (NPM) was designed with parallelism and the ability to support this situation (that MLIR doesn't? Or doesn't to the degree/way in which the NPM does). I'll leave it to folks (Chandler probably has the most context here) to provide some more detail there if they can/have time.Historically speaking, all of the LLVM pass managers have been designed to support multithreaded compilation (check out the ancient history of the WritingAnLLVMPass <http://llvm.org/docs/WritingAnLLVMPass.html> doc if curious). The problem is that LLVM has global use-def chains on constants, functions and globals, etc, so it is impractical to do this. Every “inst->setOperand” would have to be able to take locks or use something like software transactional memory techniques in their implementation. This would be very complicated and very slow. MLIR defines this away from the beginning. This is a result of the core IR design, not the pass manager design itself. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200229/8011dba8/attachment.html>
On 3/1/20 1:08 AM, David Blaikie via llvm-dev wrote:> +Chandler & Alina for new pass manager context > > On Thu, Feb 27, 2020 at 9:45 PM Nicholas Krause via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > On 2/28/20 12:19 AM, Chris Lattner wrote: > > Hi Nicholas, > > > > You might want to check out MLIR: its pass manager is already > automatically and implicitly multithreaded. > > > > -Chris > Chris, > > I was aware that LLVM was moving to MLIR at some point due to this. > > > FWIW: I don't /tihnk/ that's quite an accurate representation of the > situation. MLIR is now part of the LLVM project, but so far I haven't > seen any discussions of moving the core LLVM project itself to MLIR > (admittedly I'm not super clear on the details of MLIR or what that'd > look like - I would've guessed that LLVM would itself be a lower level > that a given MLIR stack might lower to, etc). There's been some > discussion of folks interested in experimenting with using MLIR in > Clang, though that's not a project goal right now. > > I've > curious as > to how MLIR deals with IPO as that's the problem I was running into. > > > FWIW I believe LLVM's new pass manager (NPM) was designed with > parallelism and the ability to support this situation (that MLIR > doesn't? Or doesn't to the degree/way in which the NPM does). I'll > leave it to folks (Chandler probably has the most context here) to > provide some more detail there if they can/have time.Indeed NPM does enable more parallelism compared to the old one. However this parallelism is much more useful for our "multiple JIT-compilations in one process" case where each thread is doing its own compilation on its own module/context. Independent pass pipelines, settings per pass instance, individual caching analysis managers - everything helps. Yet for the kind of multi-threaded compilation discussed here, where a single context/IR unit is shared across many threads, it becomes much more involved due to limitations of IR itself, as others have rightfully pointed out here. regards, Fedor.> Even if you have > pipelines what guarantees do we have about IPO or are there any. For > example if an > analysis pass runs after a loop pass for heuristics to get good data, > does MLIR ensure > that? The problem isn't getting a pipeline as much as IPO issues in > terms of rescheduling > in a pipeline or incorrectly splitting up into pipelines. I yet to > find > a good solution on the > GCC side as well and it seems that there will be issues with this no > matter what, not > sure of what trade offs the LLVM side is willing to make. > > The other issues is that graph data structures to my knowledge do not > allow insertion > of multiple nodes at the same time or how to scale the graphs for > callers or SSA. Not > sure if you guys have encapsulated the operators and data > structures in > a series of > classes as that would be the first part. The other part is > figuring out > how to link and > interact with build systems to launch threads from make -j or other > similar things. > > > Thanks for the notice about MLIR through maybe my IPO is not > really there > but after reading parts of it seems to be a issue through a little > smaller still > and thanks for the prompt response, > > Nick > >> On Feb 27, 2020, at 7:05 PM, Nicholas Krause via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > >> > >> Greetings All, > >> > >> For the last few months since the GCC Cauldron I've been > researching/helping out > >> plan for multi-threading GCC. I've posted my GCC ideas here: > >> > https://docs.google.com/document/d/1po_RRgSCtRyYgMHjV0itW8iOzJXpTdHYIpC9gUMjOxk/edit > >> > >> as I've heard there is interest on the LLVM side as well. I've > talked to some of the IBM folks from > >> the Toronto area about it face to face due to them having more > middle end and back end knowledge > >> then me. > >> > >> Not sure if anyone is interested in my ideas or wants me to > extend my help on the LLVM side, > >> > >> Nick > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200303/9d7073df/attachment.html>