<br><br><div>On Wed Dec 18 2013 at 4:26:56 PM, Manman Ren <<a href="mailto:manman.ren@gmail.com">manman.ren@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div>On Mon, Dec 16, 2013 at 4:05 PM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">My off the cuff idea here is to make it a module pass, but we'll split the verification a bit:<br>

<br>a) IR verification time -<div><br></div><div>Verify debug metadata attached to instructions (i.e. line information). Only check it for structure (i.e. do the various metadata nodes have the right number and kind of operands).</div>

</blockquote></div></div></div><div dir="ltr"><div><div><div>It makes things a little complicated by having verification in two places (IR verifier and the module pass).</div><div>The advantage is we can verify more frequently on structures, comparing against doing this in the module pass.</div>
</div></div></div><div dir="ltr"><div><div>
<div> </div></div></div></div></blockquote><div><br></div><div>Sure.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div><br></div><div>b) Module pass - </div><div><br></div><div>Walk down from the CUs in the file and verify everything we see.</div></blockquote><div><br></div></div></div></div><div dir="ltr"><div><div><div>This is DebugInfoFinder.processModule.</div>
</div></div></div></blockquote><div><br></div><div>Yep.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div> </div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div> I think then the only duplication we'll get are methods from classes as the context for functions. We'll also need to check the contexts on the various metadata operands on the line numbers which is unfortunate as that probably involves a separate walk over the instructions,</div>

</blockquote><div><br></div></div></div></div><div dir="ltr"><div><div><div>Yes, we need to walk over the instructions and call the various process methods of DebugInfoFinder, i.e. moving things related to debug info verifier from Verifier.cpp to its own module pass.</div>

<div>We can then verify everything stored in DebugInfoFinder, similar to the current implementation of debug info verifier.<br></div></div></div></div><div dir="ltr"><div><div><div> </div></div></div></div></blockquote><div>
<br></div><div>Agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div> but then we could cache the information we've already seen.</div></blockquote></div></div></div><div dir="ltr"><div><div><div>Not sure what you mean here.</div><div><br></div></div></div></div></blockquote><div>
<br></div><div>Figured if we walked over at the module level then we could verify that we didn't walk over some metadata (like scopes, etc) more than once during a verify.</div><div><br></div><div>-eric</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div></div><div>Thanks,</div><div>Manman</div></div></div></div><div dir="ltr"><div><div><div>
 </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div><br></div><div>Thoughts?</div><span><font color="#888888"><div><br></div><div>-eric</div></font></span><div><div><br><div>On Tue Nov 19 2013 at 10:55:38 AM, Manman Ren <<a href="mailto:manman.ren@gmail.com" target="_blank">manman.ren@gmail.com</a>> wrote:</div>

<blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">Hi all,<div><br></div><div>Currently, debug info verifier is part of the IR verifier which is a function pass.</div><div><br></div><div>One part of the IR verifier that I don't like is it verifies module-level data in doFinalization. If we have two verifier passes in a single module pass manager, doFinalization of the two passes will run on the same module data after all passes.</div>



<div><br></div><div>I followed the same model for debug info verifier: verifying debug info reachable from a function in runOnFunction and verifying module level debug info in doFinalization. But it can be time consuming (see email discussion in "Debug Info Slowing Things Down?!"), since each function can reach a lot of debug info MDNodes, some of them are shared between functions.</div>



<div><br></div><div>One possibility is to cache MDNodes verified by one function so other functions do not verify those MDNodes again. But this is a violation of Function Pass in my opinion, since other optimization passes can run between verifying one function and verifying another function, and the MDNodes verified by one function can be modified when verifying another function.</div>



<div><br></div><div>Another possibility is to separate debug info verifier into its own module pass. The disadvantage is that we have to run the IR verifier and the debug info verifier, each will traverse the module.</div>



<div><br></div><div>Comments and suggestions are welcome.</div><div><br></div><div>Thanks,</div><div>Manman</div></div>
</blockquote>
</div></div></blockquote></div></div></div></blockquote>