<div dir="ltr"><br><div class="gmail_extra"><br><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 class=""><<a href="mailto:cfe-commits@lists.llvm.org">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>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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><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 class=""><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>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<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@lists.llvm.org">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><br></div></div>