Hi,<br><br>FWIW, I'm happy with moving these tests into the test-suite. They do make sense to be expressed in a compiler-neutral manner, even though some may test clang-specific behaviour. <br><br>There is a UnitTests directory already, and adding the ability to run LIT tests should be simple within the new CMake framework. <br><br>James<br><div class="gmail_quote"><div dir="ltr">On Tue, 1 Dec 2015 at 19:09, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 1, 2015 at 10:43 AM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 1 December 2015 at 18:29, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
> Are they things the test-suite couldn't (either technically or<br>
> philosophically) cover, or only that it doesn't cover it at the moment, but<br>
> could do so?<br>
<br>
</span>IMO, it's a philosophical issue. The test-suite is a whole-program<br>
execution, and all that matters is the end result, the output of the<br>
program, not the program itself.<br>
<br>
Those tests are mostly large (> 3 lines of code) so, if we were trying<br>
to objdump and match for instruction patterns, any optimisation<br>
variance could destroy them, as well as you may find the pattern<br>
elsewhere in the same object, not belonging to the function you want<br>
(inlining, etc).</blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Not sure I follow - I'm not suggesting adding objdump/instruction checking to existing large programs in the test-suite, but adding other tests to the test-suite that do this and have appropriate input for it to be a reliable/useful form of testing.</div></div></div></div><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"> All in all, all the problems with reducing C code<br>
would be pertinent here, so a big hammer to kill small issues. On the<br>
other hand, the Clang based asm/obj examples are all small, and<br>
hand-crafted to suit the problem being tested.<br>
<br>
We could, however, add a new directory in the test-suite for that kind<br>
of tests, like we already have for regressions in C/C++. </blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>If a separate directory makes it more clear what the purpose is, sure, seems fine to me, but I don't have strong or informed opinions on exactly how the test-suite is laid out.</div></div></div></div><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">That would<br>
dissociate the front-end from the back-end, and essentially any<br>
compiler used would have to abide by the rules of the test (which may<br>
not be true for some compilers).<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>This is perhaps an interesting part/point: In theory I would think that these tests should be able to be phrased in a compiler-agnostic way, since they're testing the compiler as a whole and testing behavior that the source code demands, no?<br></div></div></div></div><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">I don't mind where they end up, really, but we need that kind of test<br>
somewhere. Clang is an easy place because we know we have it built<br>
when the Clang repo is checked out.<br>
<span><br>
<br>
> That would sort of defeat the point of having the testing and projects<br>
> separated though - it would tie the tests together and produce most of the<br>
> undesirable outcomes of having single end-to-end tests.<br>
<br>
</span>Right, I agree, but since the relationship between Clang and LLVM is<br>
non-trivial, and there are lots of changes that need to be done on<br>
both sides, I can't see why we shouldn't have tests that span across<br>
projects.<br>
<br>
Clearly, the sanitizer tests need Clang and Compiler-RT. Some Libc++<br>
tests need Compiler-RT, others need libunwind, on ARM I need Clang to<br>
build it. There are a lot of dependencies that are not there by<br>
accident, but by design.<br>
<br>
The more you move tests away from the big targets (LLVM, Clang), the<br>
less they're ran by people committing patches, and the harder will be<br>
to pick up the failures. Having said that, a decent buildbot coverage<br>
would account for most of those problems, but it would also put a<br>
stress on slow/expensive/experimental hardware support. It's a<br>
balance, I think.<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Why would it require slow/expensive/experimental hardware? (& if it does require that, how do you expect average developers to run them on a regular basis?)</div></div></div></div><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">
<span><br>
<br>
> (it would mean that at least the pure (or at least non-Clang) LLVM developer<br>
> would have a test to run where they would not if the test remained in Clang<br>
> only)<br>
<br>
</span>That is a good point. Right now, RT/libc++ tests in that category are<br>
controlled by enabling/disabling support via CMake flags. We may be<br>
able to do the same with Clang (if LLVM is not built with it, disable<br>
asm/obj tests). Moving them all to a regression package in the<br>
test-suite would be another option, but one that would take a lot<br>
longer...<br>
<br>
cheers,<br>
--renato<br>
</blockquote></div></div></div></blockquote></div>