<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; "><br><div><div>On Nov 14, 2013, at 3:28 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 14, 2013 at 3:00 PM, Pete Cooper <span dir="ltr"><<a href="mailto:peter_cooper@apple.com" target="_blank" class="cremed">peter_cooper@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>This is probably most like #1, but i would either improve (or add a verbose option to) -debug-pass=Structure. Then just write a test which calls opt with some passes and uses FileCheck to verify the debug output.</div>
</blockquote><div><br></div><div>Yes, but see the problems with it that I brought up. Note that the new pass manager makes this significantly more complex because there isn't a linear series of passes (regardless of nesting).</div></div></div></div></blockquote>CHECK-DAG? :)<br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>This is nice as it means that if anyone ever wants to verify for performance reasons that a given test invalidates a very specific set of passes and never regresses from that set then they can use FileCheck for this.</div>
</blockquote><div><br></div><div>I don't think these are realistic or good tests in the new model... I'm not really sure what we're gaining from this at all. It sounds like a much worse case of what other people are complaining about with unit tests?</div></div></div></div></blockquote>I disagree. To add to those against unit tests, most of us work with FileCheck failures every day. We're used to debugging them quickly by reading and comparing the IR/assembly against the CHECK lines.</div><div><br></div><div>Having your code emit text to debug itself is far easier for all of us than having to open a gmock test in a debugger then try to understand how to even debug the new pass manager. Arguably as much of our LLVM code as possible should be able to dump strings we can usefully check in FileCheck, but we aren't doing that right now.</div><div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>And it looks like debug-pass is available on release builds.</div></blockquote><div><br>
</div><div>... not always. Certainly, with the added complexity needed to check a system that uses active caching, I don't think we would want it in release builds. </div></div></div></div></blockquote>Fair enough. You know your plans on this code better than I do, and whats appropriate on debug/release.</div><div><br></div><div>But i don't see this as a problem. Most build bots run on multiple different configurations. Having your tests only on debug or assert builds isn't a huge issue given the amount of testing of those configurations.<br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><br></div></div>
</blockquote></div><br></body></html>