<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 16, 2019 at 12:54 PM David Greene via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Renato Golin via Openmp-dev <<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a>> writes:<br>
<br>
> But if we have some consensus on doing a clean job, then I would<br>
> actually like to have that kind of intermediary check (diagnostics,<br>
> warnings, etc) on most test-suite tests, which would cover at least<br>
> the main vectorisation issues. Later, we could add more analysis<br>
> tools, if we want.<br>
<br>
I think this makes a lot of sense.<br>
<br>
> It would be as simple as adding CHECK lines on the execution of the<br>
> compilation process (in CMake? Make? wrapper?) and keep the check<br>
> files with the tests / per file.<br>
<br>
Yep.<br>
<br>
> I think we're on the same page regarding almost everything, but<br>
> perhaps I haven't been clear enough on the main point, which I think<br>
> it's pretty simple. :)<br>
<br>
Personally, I still find source-to-asm tests to be highly valuable and I<br>
don't think we need test-suite for that.  Such tests don't (usually)<br>
depend on system libraries (headers may occasionally be an issue but I<br>
would argue that the test is too fragile in that case).<br>
<br>
So maybe we separate concerns.  Use test-suite to do the kind of<br>
system-level testing you've discussed but still allow some tests in a<br>
monorepo top-level directory that test across components but don't<br>
depend on system configurations.<br>
<br>
If people really object to a top-level monorepo test directory I guess<br>
they could go into test-suite but that makes it much more cumbersome to<br>
run what really should be very simple tests.</blockquote><div><br></div><div>The main thing I see that will justify push-back on such test is the maintenance: you need to convince everyone that every component in LLVM must also maintain (update, fix, etc.) the tests that are in other components (clang, flang, other future subproject, etc.). Changing the vectorizer in the middle-end may require now to understand the kind of update a test written in Fortran (or Haskell?) is checking with some Hexagon assembly. This is a non-trivial burden when you compute the full matrix of possible frontend and backends.</div><div>Even if you write very small tests for checking vectorization, what is next? What about unrolling, inlining, loop-fusion, etc. ? Why would we stop the end-to-end FileCheck testing to vectorization?</div><div><br></div><div>So the monorepo vs the test-suite seems like a false dichotomy: if such tests don't make it in the monorepo it will be (I believe) because folks won't want to maintain them. Putting them "elsewhere" is fine but it does not solve the question of the maintenance of the tests.</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div></div></div>