[llvm-dev] Multi-Threading Compilers
Nicholas Krause via llvm-dev
llvm-dev at lists.llvm.org
Fri Mar 20 12:34:39 PDT 2020
On 3/20/20 2:11 PM, Chris Lattner wrote:
>> On Mar 19, 2020, at 2:31 PM, Johannes Doerfert
>> <johannesdoerfert at gmail.com <mailto:johannesdoerfert at gmail.com>> wrote:
>> I think addressing this issue first makes sense. I would however start
>> by determining the actual impact of different design choices here. I
>> mean, do we know locks will be heavily contented? If I had to guess I'd
>> say most passes will not create or modify functions nor add or remove
> 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.
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.
Thanks and if this is a real concern we should get data for it then or
other llvm:Value issues,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev