[llvm-dev] Multi-Threading Compilers

[David Blaikie via llvm-dev]

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

- Dave


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