<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 25, 2018, at 9:08 AM, Zachary Turner <<a href="mailto:zturner@google.com" class="">zturner@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">But is there a reason why that is more valuable with LLDB than it is with LLVM? In LLVM when a test fails it stops and doesn't run subsequent run lines. So you have the same issue there. </div></div></blockquote><div><br class=""></div><div>That's not a good analogy. Multiple RUN lines don't necessarily mean separate tests, they mean separate commands being executed that may depend on each other. As Pavel pointed out before, this would be closer to how gtests behave.</div><div><br class=""></div><div>-- adrian</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">The way this is handled in LLVM is that if you think tests are sufficiently different that they could be broken by different types of changes, you split them up into different files.<div class=""><br class=""></div><div class="">Do you feel LLDB is fundamentally different in this regard?</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Apr 25, 2018 at 8:27 AM Adrian Prantl <<a href="mailto:aprantl@apple.com" class="">aprantl@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class="">Disregarding the added complexity I believe that being able to communicate the number of tests filed/passed inside a single file would be very valuable. For example when one test gets broken by upstream clang changes and it takes a few days to fix it properly, we don't want to loose signal on the other tests in the same file during that period. I think it's worth it.<div class=""><br class=""></div><div class=""></div></div><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class="">-- adrian</div></div><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Apr 25, 2018, at 8:13 AM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank" class="">zturner@google.com</a>> wrote:</div><br class="m_-3363268229985282133Apple-interchange-newline"><div class="">Well let’s see what Davide and Adrian think. I’m more of an outsider these days so consider my perspective an llvm-centric one, which would sometimes (but not always) be the best for lldb<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Apr 25, 2018 at 12:31 AM Pavel Labath via Phabricator <<a href="mailto:reviews@reviews.llvm.org" target="_blank" class="">reviews@reviews.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">labath added a comment.<br class="">
<br class="">
In <a href="https://reviews.llvm.org/D46005#1077016" rel="noreferrer" target="_blank" class="">https://reviews.llvm.org/D46005#1077016</a>, @zturner wrote:<br class="">
<br class="">
> Note that there's currently no precedent (that i'm aware of anwyay) in LLVM or any of its subprojects for splitting the running of a single file into multiple parallel jobs. All of LLVM's other projects parallelize at file granularity, and so it's up to to the person writing tests to ensure that the file granularity matches that with which they want tests to be parallelized at.<br class="">
<br class="">
<br class="">
There's always gtest. Regardless of whether you consider a .cpp file or the built exectable to be a "test file", it will generally contain a number of tests. And arguably, our test suite is more similar to the gtest suite than the traditional lit (ShTest) suites (for one, it hijacks a third party unit testing library, and then tries to make it run under lit). And we run all gtest tests individually (I've often wondered what kind of performance impact that has, but they seem to be running fast enough anyway...).<br class="">
<br class="">
For what it's worth, paralelization is not my motivation here. There some tests which run disproportionately long, and this will speed them up, but that may be offset by the fact we need to start more work this way (if anyone is interested I can try to do some measurements). My main reason for doing this is so that we can have better mapping of test result states. As it stands now, we only have two possible results for a test: passed or failed. Lit has more results than that, and they roughly match the existing dotest states (the different treatment of XFAILs is the biggest difference), so it should be possible to represent them with more fidelity. However, right now it's not possible to translate them reasonably, as a "single test" can result in any number of fails/xfails/skips/... (or no results at all).<br class="">
<br class="">
> That doesn't mean it's not possible (as you've shown here), but it adds some additional complexity and I'm not sure it's worth it.<br class="">
<br class="">
It adds complexity, but not much imho. I was actually pleasantly surprised at how easy it was to pull this off. The entire implementation is 78 LOC right now. The changes to the test format will probably push it over a 100, but not by much.<br class="">
<br class="">
That said, I am not interested in forcing this onto everyone. I did it because it seemed like a nice thing to have and I was curious if it is doable (easily). However, if there's no interest for it, then I can just abandon it..<br class="">
<br class="">
<br class="">
<a href="https://reviews.llvm.org/D46005" rel="noreferrer" target="_blank" class="">https://reviews.llvm.org/D46005</a><br class="">
<br class="">
<br class="">
<br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></div></blockquote></div>
</div></blockquote></div><br class=""></body></html>