[llvm-dev] Multi-Threading Compilers

[Chris Lattner via llvm-dev]

> 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!

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200321/5fde2831/attachment.html>