<div class="gmail_extra"><div class="gmail_quote">I'm adding the dev list to this discussion, as it's a bit meta, and not specific to these patches.</div><div class="gmail_quote"><br></div><div class="gmail_quote">
On Thu, Aug 16, 2012 at 12:55 PM, Will Schmidt <span dir="ltr"><<a href="mailto:will_schmidt@vnet.ibm.com" target="_blank" class="cremed">will_schmidt@vnet.ibm.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 Thu, 2012-08-16 at 15:06 -0400, Rafael Espíndola wrote:<br>
> On 16 August 2012 14:33, Chandler Carruth <<a href="mailto:chandlerc@google.com" class="cremed">chandlerc@google.com</a>> wrote:<br>
> > Test cases?<br>
><br>
> We discussed this a bit on IRC. It is my impression that we already<br>
> went too far with PPC ELF without testing. As Roman itself noticed two<br>
> days ago, it is possible to break hello word on ppc elf and not notice<br>
> it:<br>
<br>
><br>
> <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120813/148239.html" target="_blank" class="cremed">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120813/148239.html</a><br>
><br>
> We have been too slow to add tests, even when we noticed that entire<br>
> functions could be deleted and the tests would still pass:<br>
><br>
> <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20111219/133931.html" target="_blank" class="cremed">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20111219/133931.html</a><br>
> (which btw, is still the case on trunk).<br>
><br>
> So sorry for the current state for those starting to hack now on pcc<br>
> elf, but to make sure we are in a better position tomorrow I think we<br>
> have to start requiring tests as features are added and hopefully also<br>
> cover the backlog we have so far.<br>
<br>
</div></div>Hi all,<br>
The changes so far are an attempt to get existing test cases to run.  So<br>
I'd argue against the changes being considered new features.  :-)<br></blockquote><div><br></div><div>Yea, new features is probably the wrong word. Let's say "new code". =]</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2003-01-04-ArgumentBug.ll is the one chosen at random that Adhemerval<br>
has been focused on.  That wasn't called out explicitly, and we do<br>
expect some number of test cases to begin functioning better once this<br>
initial batch of patches gets worked into the tree.<br></blockquote><div><br></div><div>This is good, but where is this test? :: runs find ::  Ah, its in the JIT. Ok, it's not clear that this is the best test to start with, but let's not get ahead of ourselves...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What got us in trouble here is that we didn't understand the<br>
'test-suite' as being a separate batch of tests from 'make check', and<br>
simply didn't know to run it.  (Until after Roman hit them and reported<br>
the regressions to us).</blockquote><div><br></div><div>The test-suite is good to run, but it's not really what Rafael or I are referring to here.</div><div><br></div><div>Tests in LLVM can be broken down into a few categories:</div>
<div><br></div><div>1) Direct unittests of core APIs in llvm/unittests</div><div>2) Direct testing of the output of the various analyses, transformations, etc., in llvm/test</div><div>3) Testing the execution of compiled small programs by building them and running them on test hardware (possibly the host, possibly not). These are in test-suite/SingleSource/UnitTests and projects/test-suite/SingleSource/Regression</div>
<div>4) Testing the execution of large "real world" programs in the nightly test suite after building with the Clang/LLVM toolchain. These consist of everything else in the test-suite/, especially the test-suite/MultiSource side of things</div>
<div><br></div><div>We don't expect the latter two to be used on every single check-in. We have build bots that run them, and you should use them whenever changing something in a way that is risky or may well have failures that only show up in the last "whole system" testing pattern.</div>
<div><br></div><div>We expect nearly every patch[1] to be covered to some extent either by unittests of the APIs or by FileCheck-driven output-tests in 'test/...'. The reason for this split in importance is that these first two don't require any particular hardware or execution environment, and thus are suitable to require every developer run and pass on every checkin. This is what Rafael and I are looking for in these patches, as they will ensure developers who don't have a PowerPC system to run any execution tests on don't immediately break that backend. =]</div>
<div><br></div><div>Now, as Rafael is alluding to, there is an unfortunate reality: we don't have enough tests in the tree to cover the *existing* PowerPC support, much less to cover your additions. That means you may need to add tests for the existing PPC support, just to be able to fix a bug in and have a test that covers that fix . I hope this isn't too much of a burden, as it will greatly improve the quality of our PPC support.</div>
<div><br></div><div>The common pattern when building up support for a platform is to take some of the execution tests in #3 and #4 which aren't working correctly, figure out what isn't working, and what the output of the compiler *should* be in order for it to work. Then to write a very small test which produces the wrong output, and use FileCheck within it to assert that the correct output is instead produced, and include that with the fix as a new test in #1 or #2. This way, we won't regress even if we don't run the complete test suites.</div>
<div><br></div><div>If everything currently in #3 and #4 works correctly, but other programs don't, my suggestion would be to follow essentially the same process with whatever system-tests you have that are failing. We're hoping to make it easier in the future to contribute new system tests to #4, but currently it's a bit painful.</div>
<div><br></div><div><br></div><div>Now, the JIT tests are just really really special. Honestly, I would ignore them and JIT in general until the normal Clang/LLVM static compilation pipeline is working well and well tested. Then ask on llvmdev for how best to test JIT problems if you still have them. =]</div>
<div><br></div><div>Hopefully not too much information overload! =] Let me know if I can clarify anything.</div><div>-Chandler</div><div><br></div><div><br></div><div>PS: You really don't need to read the foot notes... ;] I'm long winded.</div>
<div><br></div><div>[1] Yea, "nearly" is kind-of annoying here. If you're curious, here is how I would break it down further:</div><div><br></div><div>There are a few things inside of LLVM that are not in an easily testable state. For example, the inner details of the register allocator. Some of these cases we can't add tests for because we have to have a function that needs N-thousands of virtual registers before the bad code path is taken. We're actively trying to reduce the amount of LLVM's pipeline that is subject to this though, so its important to try to find a way to test these things first.</div>
<div><br></div><div>There are also patches where adding a test is infeasible: for example patches that make algorithms not be n^2 or exponential. In some cases, the inputs that trigger these are necessarily too large to include in a human-readable test suite.</div>
<div><br></div><div>Finally there are lots of patches which just don't need testing. These are refactorings, cleanups, and other things which don't actually add, remove, or change functionality, and thus they should already be covered by existing tests.</div>
</div></div>