[llvm-dev] Multi-Threading Compilers

[Nicholas Krause via llvm-dev]

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
>> calls.
>
> 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.

Thanks and if this is a real concern we should get data for it then or 
other llvm:Value issues,
Nick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200320/29feb81c/attachment.html>