[llvm-dev] Multi-Threading Compilers
Doerfert, Johannes via llvm-dev
llvm-dev at lists.llvm.org
Wed Mar 25 00:52:28 PDT 2020
On 3/21/20 11:29 AM, Chris Lattner wrote:
>> On Mar 20, 2020, at 12:34 PM, Nicholas Krause <xerofoify at gmail.com>
>>> 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.
>> 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
We wouldn't need to lock every setOperand call but only the ones that
set a constant operand.
More information about the llvm-dev