<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 1, 2015 at 10:45 AM 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></div></blockquote><div><br></div><div>FWIW to elaborate here on a place I know we can't test well at the moment is the creation of the TargetMachine itself. This is why I've been trying to pull as much stuff out of the API call and put it into the IR where possible. It's a lot of refactoring to keep it particularly clean which is why it's slow going.</div><div><br></div><div>-eric</div><div> </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></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></div>