> On Mar 19, 2020, at 2:31 PM, Johannes Doerfert <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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200320/b1c82453/attachment.html>
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. > > -ChrisHi 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>
> 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>