You cannot test the intrinsic emission with the same quality when splitting the test in two. You miss testing the producer consumer relationship between the two components. <br><br>I'm sorry that this use case appears to you as not qualifying. <br><div class="gmail_quote"><div dir="ltr">On Tue, 1 Dec 2015 at 18:45, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@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_quote"><div dir="ltr">On Tue, Dec 1, 2015 at 10:43 AM James Molloy via cfe-commits <<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br><br>> That would sort of defeat the point of having the testing and projects separated though - it would tie the tests together and produce most of the undesirable outcomes of having single end-to-end tests. <br><br>End to end tests have significant disadvantages as we all know. However they do have some advantages too( that I have already enumerated) and the question currently as I see it is how do we best get/keep those advantages in our testing strategy?<br><br>W.r.t the test-suite, that is a possibility. There are currently no codegen-filecheck tests in the test-suite but there seems to be no reason I can see why not. The disadvantage there for me is that we take short running, simple tests and demote them to be run less often.<br><br>Would it make sense to have a dedicated subdirectory in clang/test for these kind of tests, so they can be directly enumerated and therefore kept to a minimum , yet be allowed when they add value?<br><br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>There are a few cases where we can't currently test something, but none of the cases you or Renato have brought up qualify. I'm curious what you'd put in this directory?</div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><div>-eric</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">James<br><div class="gmail_quote"><div dir="ltr">On Tue, 1 Dec 2015 at 18:29, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">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 9:56 AM, Renato Golin via cfe-commits <span dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 1 December 2015 at 17:23, James Molloy via cfe-commits<br>
<span><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>> wrote:<br>
> This isn't just a NEON intrinsics thing, and this isn't just an ARM/AArch64<br>
> thing. There needs to be some way to test the compiler from start to finish.<br>
> Not being able to do so leaves serious coverage holes.<br>
<br>
</span>Just for the sake of completeness, a hole that the test-suite doesn't cover.<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Are they things the test-suite couldn't (either technically or philosophically) cover, or only that it doesn't cover it at the moment, but could do so?</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>
> CodeGen/aarch64-fix-cortex-a53-835769.c, where we absolutely 100% must<br>
> ensure that the -mfix-cortex-a53-835769 flag gets properly respected in the<br>
> compiler output.<br>
<br>
</span>SIMD intrinsics (including NEON, SSE), Errata fixes, Procedure call<br>
tests, ELF section placement, FP contracts, Debug info, Inline<br>
assembly, Unicode support, object creation, library symbol clashes,<br>
back-end diagnostics are some of the examples that need to go all the<br>
way to asm or object code.<br>
<span><br>
<br>
> If you can describe a way to get the same strength of testing without<br>
> running the backend during clang tests, I'm all ears!<br>
<br>
</span>I'm particularly interested in how do we keep the IR printed in the<br>
Clang tests in sync with the IR sent to the LLVM tests if/when they<br>
change, to guarantee that Clang changes don't generate silent codegen<br>
faults down the line in LLVM and vice-versa.<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>That would sort of defeat the point of having the testing and projects separated though - it would tie the tests together and produce most of the undesirable outcomes of having single end-to-end tests. <br><br>(it would mean that at least the pure (or at least non-Clang) LLVM developer would have a test to run where they would not if the test remained in Clang only)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
cheers,<br>
--renato</blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<div><div>_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits</a><br>
</div></div></blockquote></div></div></div></blockquote></div>
_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits</a><br>
</blockquote></div></div></blockquote></div>