<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"> As far as I'm aware, the only way this happens is if you continually destroy and re-create your passmanager</div></div></blockquote><br class=""></div><div class="">FPPassManager::runOnFunction also (indirectly) calls PassRegistry::getPassInfo. I think this is the reason for the 5% (what I'm seeing).</div><div class=""><br class=""></div><div class="">But anyway, if you strongly disagree with this patch I can revert it. Both problems I mentioned are not big problems.</div><div class=""><br class=""></div><div class="">Erik</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 05 Mar 2015, at 01:54, Chandler Carruth <<a href="mailto:chandlerc@google.com" class="">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra">Sorry it has taken some time to reply, but I firmly disagree with this patch. I do not think this is the correct direction for LLVM. It makes an already confusing and poorly understood API easy to use in a buggy way by becoming modal in its concurrency. I think that is the wrong design.</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Feb 27, 2015 at 7:21 AM, Erik Eckstein <span dir="ltr" class=""><<a href="mailto:eeckstein@apple.com" target="_blank" class="">eeckstein@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":880" class="a3s" style="overflow:hidden">Hi Owen, Chandler,<br class="">
<span class=""><br class="">
> Do you mean with a release *+* asserts build?<br class="">
<br class="">
<br class="">
</span>Yes, sorry I wrote it wrong.<br class="">
<br class="">
I think initial description was not very good. I'll try to explailn again: there are two issues<br class="">
<br class="">
1. multithread-performance problem in the assert build: I understand that assert builds are slower than release builds, but in this case it's a factor of 4 when running with 4 threads, i.e. the multithreaded version is slower than the single-threaded version! This makes the asserts build useless for my purpose.<br class=""></div></blockquote><div class=""><br class=""></div><div class="">I would much rather remove the assert than add this complexity. I think making the synchronization contract of an API modal and subtle in this way is a terrible tradeoff to fix a performance problem in an *asserts* build.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":880" class="a3s" style="overflow:hidden">
<br class="">
2. Even in the release build there is a performance penalty of about 5% because of the mutex.</div></blockquote></div><br class="">You mean without asserts at all? I cannot reproduce this and I have tried very hard. As far as I'm aware, the only way this happens is if you continually destroy and re-create your passmanager. If you stop doing that, the performance hit should go away.</div></div>
</div></blockquote></div><br class=""></body></html>