Ok, understood. <br><br>I think I'd be OK with demoting these tests to the test-suite, and dealing with the slightly lower amount of testing that comes with it if it means we can keep the clang tests in a nice shape. <br><br>We'd need to ensure there were equivalent tests written that test only clang produced IR - many tests will have this already but some don't. <br><br>James<br><div class="gmail_quote"><div dir="ltr">On Tue, 1 Dec 2015 at 19:51, 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:42, James Molloy <<a href="mailto:james@jamesmolloy.co.uk" target="_blank">james@jamesmolloy.co.uk</a>> wrote:<br>
> Why do you think it would be non trivial? Some simple lit tests aren't<br>
> exactly arduous on most targets.<br>
<br>
I mean having more points in the testing matrix.<br>
<br>
Clang check-all is cheaper than running the test-suite, but if we<br>
start moving more tests to the suite, we'll have to run it for more<br>
combinations. For slow targets, that mostly means a new buildbot,<br>
because you want the "fast" check-all to not be impeded by the "slow"<br>
test-suite for every commit.<br>
<br>
The "non-trivial" amount is the sole difference in how many machines<br>
you can get to have a reasonable amount of commits in the blame-list<br>
for everything we test, which is trivial on fast x86_64 servers.<br>
<br>
--renato<br>
</blockquote></div>