Hi Renato,<br><br>> by a non-trivial amount.<br><br>Why do you think it would be non trivial? Some simple lit tests aren't exactly arduous on most targets. <br><br>James<br><div class="gmail_quote"><div dir="ltr">On Tue, 1 Dec 2015 at 19:39, Renato Golin <<a href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 1 December 2015 at 19:09, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
> Not sure I follow - I'm not suggesting adding objdump/instruction checking<br>
> to existing large programs in the test-suite, but adding other tests to the<br>
> test-suite that do this and have appropriate input for it to be a<br>
> reliable/useful form of testing.<br>
<br>
Sorry, I was building to that... But currently, the test-suite<br>
compiles the code into an executable, then run it. Changing that<br>
premise means we'll have something other than the test-suite we always<br>
had, and may bring other problems, like too many hats for the<br>
infrastructure to keep, especially now that James is moving it to<br>
integrate with lit. We may decide this is the way to go, but we need<br>
to make clear all the pros and cons of doing so beforehand.<br>
<br>
<br>
> This is perhaps an interesting part/point: In theory I would think that<br>
> these tests should be able to be phrased in a compiler-agnostic way, since<br>
> they're testing the compiler as a whole and testing behavior that the source<br>
> code demands, no?<br>
<br>
There's where things get interesting. Say we change the test-suite to<br>
instead of compiling and running, just compile to asm/obj and<br>
grep/objdump to match instructions, ELF sections, debug symbols, etc.<br>
<br>
Some tests are easy to make compiler independent. Intrinsics tests<br>
fall into that category. Most currently in Clang tests could move<br>
directly to the test-suite as soon as we have such infrastructure.<br>
<br>
Other tests, however, are specific to Clang+LLVM that may make no<br>
sense to GCC or ICC, ARMCC etc. Those tests, would have to be in yet<br>
another separate directory, that is only enabled if the compiler is<br>
Clang, assuming the back-end is always LLVM.<br>
<br>
These are all options that, for me, have equal value with keeping them<br>
in Clang. AFAICS, they stir the same kind of problems wherever they<br>
are tested.<br>
<br>
<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>
><br>
> Why would it require slow/expensive/experimental hardware? (& if it does<br>
> require that, how do you expect average developers to run them on a regular<br>
> basis?)<br>
<br>
You misunderstood. It would "put a stress on", not "require".<br>
Basically, it would increase the cost of testing on those classes of<br>
hardware more than off-the-shelf hardware by a non-trivial amount.<br>
<br>
This goes back to our discussion on buildbots, where some targets are<br>
harder to find hardware than others, and when you do, they're slower.<br>
Meaning the more variations we need to test, the more hardware you<br>
have to have to make it in any reasonable time. While a single 64-core<br>
Xeon can cope with most testing (including self-hosting, test-suite,<br>
sanitizers, libc++) on a per-commit basis, there is nothing similar,<br>
widely available, today for most other targets.<br>
<br>
But that's another discussion entirely, let's not dwell into that again. :)<br>
<br>
cheers,<br>
--renato<br>
</blockquote></div>