<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 18, 2013 at 11:55 AM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Nov 18, 2013 at 11:06 AM, Manman Ren <<a href="mailto:manman.ren@gmail.com">manman.ren@gmail.com</a>> wrote:<br>

><br>
><br>
><br>
> On Mon, Nov 18, 2013 at 10:55 AM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Sun, Nov 17, 2013 at 6:35 PM, Manman Ren <<a href="mailto:manman.ren@gmail.com">manman.ren@gmail.com</a>> wrote:<br>
>> > Hi Bill,<br>
>> ><br>
>> > Thanks for the testing case. Most of the time is spent on debug info<br>
>> > verifier.<br>
>> > I fixed a bug in r194974, now it takes too long to run debug info<br>
>> > verification.<br>
>> ><br>
>> > Debug info verifier is part of the verifier which is a Function Pass.<br>
>> > Tot<br>
>> > currently tries to pull all reachable debug info MDNodes in each<br>
>> > function,<br>
>> > which is too time-consuming. The correct fix seems to be separating<br>
>> > debug<br>
>> > info verification to its own module pass.<br>
>> ><br>
>> > I will disable the debug info verifier until a correct fix is found.<br>
>> ><br>
>><br>
>> Most likely what's going on here is that we're verifying the same sets<br>
>> of debug info multiple times. A way to quickly speed it up would be to<br>
>> cache/memoize the nodes we've already visited.<br>
><br>
><br>
> Yes, we are verifying some debug info MDNodes multiple times. I am not sure<br>
> if caching MDNodes visited in one function makes sense.<br>
> For each function, we apply a series of passes, so there are optimizations<br>
> run between verifying one function and verifying another function.<br>
> The content of MDNodes verified in one function can potentially change when<br>
> we are trying to verify another function.<br>
><br>
<br>
</div></div>I figured this was happen at bitcode load time. If we're verifying<br>
anywhere else then we should still cache per-function what we've<br>
analyzed.<br></blockquote><div><br></div><div>Verifier can be called a few times, for LTO, it is called 3 times.</div><div>It is common that we call verifier before optimization and on completion of optimization.</div><div>
>From the current source codes, verifier is grouped with a few analysis passes, so it should be</div><div>okay to cache the results. But there is no guarantee that verifier will not be grouped together with</div><div>optimization passes in a single FPPassManager. In that case, caching may not make sense since</div>
<div>the optimization passes can modify the MDNodes.</div><div><br></div><div>Currently we perform module-level verification in doFinalization which is not ideal. For example, if we have</div><div>two verifier passes, doFinalization for the two passes will be run at the end, which is a total duplication since they</div>
<div>will be verifying the same module twice, at the end of optimizations.</div><div><br></div><div>So that is one advantage of moving debug info verifier to its own module pass.</div><div><br></div><div>Manman</div><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
-eric<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> Manman<br>
><br>
>><br>
>><br>
>> -eric<br>
>><br>
>> > Thanks,<br>
>> > Manman<br>
>> ><br>
>> ><br>
>> ><br>
>> > On Sun, Nov 17, 2013 at 6:04 PM, Bill Wendling <<a href="mailto:isanbard@gmail.com">isanbard@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> I think it might be. I’m attaching a preprocessed file that can show<br>
>> >> the<br>
>> >> problem. Compile it with ToT.<br>
>> >><br>
>> >> $ clang++ -g -fvisibility-inlines-hidden -fno-exceptions -fno-rtti<br>
>> >> -fno-common -Woverloaded-virtual -Wcast-qual -fno-strict-aliasing -m64<br>
>> >> -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings<br>
>> >> -Wcovered-switch-default -Wno-uninitialized<br>
>> >> -Wno-missing-field-initializers<br>
>> >> -c LLVMTidyModule.ii<br>
>> >><br>
>> >> -bw<br>
>> >><br>
>> >><br>
>> >></div></div></blockquote></div></div></div>