[llvm-dev] Multi-Threading Compilers

[Chris Lattner via llvm-dev]

> On Mar 26, 2020, at 8:26 AM, Doerfert, Johannes <jdoerfert at anl.gov> wrote:
> 
> On 3/26/20 5:53 AM, Florian Hahn wrote:
>>> It also doesn't solve the problem of Functions themselves -- those are
>>> also GlobalValues…
>> 
>> 
>> I am not sure why not. Function passes should only rely on the information at the callsite & from the declaration IIRC. For functions, we coulkd add extra declarations and update the call sites. But I might be missing something.
> 
> FWIW, I think deleting and creating functions (or globals in general) 
> should be hidden behind an API that would allow us to synchronize things 
> in parallel runs.
> 
> I don't believe there are many passes that would be affected and we 
> could "easily" make this happen. Hide the constructors and destructors 
> so that only the friend API can access it.

Right, this is what MLIR does.  However, keep in mind that this is just one piece of the puzzle.  You also have things like ValueHandles which get owned by IPA passes.  The CallGraph used by the inline persists across function pass manager runs, and needs to be correctly updatable in order to run CallGraphSCC passes.

Getting to a multithread clean optimizer is not one bug fix away - this is a multiyear journey, and I would prefer not to see big changes with unclear tradeoffs made in an effort to get a quick win.

Instead, let’s break down the problems and fix them (the right way!) one at a time.  For example, it seems that the thread agrees that the overall design of constants are a problem: let's talk about (incrementally!) moving constants to the right architecture.  There are good suggestions about this upthread.

-Chris