[llvm-dev] Multi-Threading Compilers (original) (raw)

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Sat Feb 29 14:25:11 PST 2020

On Sat, Feb 29, 2020 at 2:19 PM Chris Lattner <clattner at nondot.org> wrote:

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).

I think the specific thing that might'v been a bit different in the NPM was to do with analysis invalidation in a way that's more parallelism friendly than the previous one - but I may be misrepresenting/misundrstanding some of it.

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.

Oh, yeah - I recall that particular limitation being discussed/not addressed as yet.

MLIR defines this away from the beginning. This is a result of the core IR design, not the pass manager design itself.

What does MLIR do differently here/how does it define that issue away? (doesn't have use-lists built-in?)

-Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200229/66785604/attachment.html>

More information about the llvm-dev mailing list