[llvm-dev] Multi-Threading Compilers
Chris Lattner via llvm-dev
llvm-dev at lists.llvm.org
Sat Mar 21 09:29:11 PDT 2020
> 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.
> 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!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev