[llvm-dev] Multi-Threading Compilers

[Doerfert, Johannes via llvm-dev]

On 3/21/20 11:29 AM, Chris Lattner wrote:
 >
 >
 >> On Mar 20, 2020, at 12:34 PM, Nicholas Krause <xerofoify at gmail.com> 
wrote:
 >>
 >>>
 >>> The problem isn’t constants or functions themselves, it is that they
 >>> are instances of llvm::Value.  Everything that walks a use/def list
 >>> would have to run code that checks for this, and every call to
 >>> inst->setOperand() would have to do locking or conditional locking.
 >>> This would be a significant across-the-board slowdown for the
 >>> compiler even when globals and constants are not involved.
 >>>
 >>> -Chris
 >>
 >> Hi Chris,
 >>
 >> Thanks for the comments. Sure that may be true but I would prefer to 
get real data to see how shared data actually looks. We can
 >> argue over it at a theoretical level. However with any real 
mutli-threading of a code base, real data is required. I've not sure about
 >> setOperand() or other llvm:Value issues but real data is more my 
concern. Sure it may turn out that is the case but I would prefer
 >> to have data as guessing with multi-threaded code in terms of 
locking/scaling is always bad or even assuming issues.
 >
 > I also love and endorse the collection of real data here!

Right, actual data would be great.


I think the solution space for the value/use-list issue might be larger
than what was mentioned so far.


Some random thoughts:

If no pass ever walks the use list of a constant, except globals which
we could handle differently, we could get rid of their use-list or
overwrite their use-list interface functions to make them no-ops. We
could also do this kind of specialization in the Use class (I think).

When creating a constant we could provide the function in which the
constant is used. We have a ConstantExpr wrapper per function to make
the constants local (similar to what I understand the MLIR design is).
We would not get pointer comparison between constants used in different
functions but I suspect the places we need this we can specialize
accordingly.

We wouldn't need to lock every setOperand call but only the ones that
set a constant operand.



 > -Chris
 >
 >