<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<div class="moz-cite-prefix">On 10/8/19 9:49 AM, David Greene via
llvm-dev wrote:<br>
</div>
<blockquote type="cite" cite="mid:nnga7abmbbi.fsf@cray.com">
<pre class="moz-quote-pre" wrap="">[ I am initially copying only a few lists since they seem like
the most impacted projects and I didn't want to spam all the mailing
lists. Please let me know if other lists should be included. ]
I submitted D68230 for review but this is not about that patch per se.
The patch allows update_cc_test_checks.py to process tests that should
check target asm rather than LLVM IR. We use this facility downstream
for our end-to-end tests. It strikes me that it might be useful for
upstream to do similar end-to-end testing.
Now that the monorepo is about to become the canonical source of truth,
we have an opportunity for convenient end-to-end testing that we didn't
easily have before with svn (yes, it could be done but in an ugly way).
AFAIK the only upstream end-to-end testing we have is in test-suite and
many of those codes are very large and/or unfocused tests.
With the monorepo we have a place to put lit-style tests that exercise
multiple subprojects, for example tests that ensure the entire clang
compilation pipeline executes correctly. We could, for example, create
a top-level "test" directory and put end-to-end tests there. Some of
the things that could be tested include:
- Pipeline execution (debug-pass=Executions)
- Optimization warnings/messages
- Specific asm code sequences out of clang (e.g. ensure certain loops
are vectorized)
- Pragma effects (e.g. ensure loop optimizations are honored)
- Complete end-to-end PGO (generate a profile and re-compile)
- GPU/accelerator offloading
- Debuggability of clang-generated code
Each of these things is tested to some degree within their own
subprojects, but AFAIK there are currently no dedicated tests ensuring
such things work through the entire clang pipeline flow and with other
tools that make use of the results (debuggers, etc.). It is relatively
easy to break the pipeline while the individual subproject tests
continue to pass.
I realize that some folks prefer to work on only a portion of the
monorepo (for example, they just hack on LLVM). I am not sure how to
address those developers WRT end-to-end testing. On the one hand,
requiring them to run end-to-end testing means they will have to at
least check out and build the monorepo. On the other hand, it seems
less than ideal to have people developing core infrastructure and not
running tests.
I don't yet have a formal proposal but wanted to put this out to spur
discussion and gather feedback and ideas. Thank you for your interest
and participation!</pre>
</blockquote>
<p>The two major concerns I see are a potential decay in component
test quality, and an increase in difficulty changing components.
The former has already been discussed a bit downstream, so let me
focus on the later.</p>
<p>A challenge we already have - as in, I've broken these tests and
had to fix them - is that an end to end test which checks either
IR or assembly ends up being extraordinarily fragile. Completely
unrelated profitable transforms create small differences which
cause spurious test failures. This is a very real issue today
with the few end-to-end clang tests we have, and I am extremely
hesitant to expand those tests without giving this workflow
problem serious thought. If we don't, this could bring
development on middle end transforms to a complete stop. (Not
kidding.)<br>
</p>
<p>A couple of approaches we could consider:</p>
<ol>
<li>Simply restrict end to end tests to crash/assert cases. (i.e.
no property of the generated code is checked, other than that it
is generated) This isn't as restrictive as it sounds when
combined w/coverage guided fuzzer corpuses.<br>
</li>
<li>Auto-update all diffs, but report them to a human user for
inspection. This ends up meaning that tests never "fail" per
se, but that individuals who have expressed interest in
particular tests get an automated notification and a chance to
respond on list with a reduced example. <br>
</li>
<li>As a variant on the former, don't auto-update tests, but only
inform the *contributor* of an end-to-end test of a failure.
Responsibility for determining failure vs false positive lies
solely with them, and normal channels are used to report a
failure after it has been confirmed/analyzed/explained.</li>
</ol>
<p>I really think this is a problem we need to have thought through
and found a workable solution before end-to-end testing as
proposed becomes a practically workable option. <br>
</p>
<p>Philip<br>
</p>
</body>
</html>