[llvm-dev] RFC: End-to-end testing

[Philip Reames via llvm-dev]

On 10/8/19 9:49 AM, David Greene via llvm-dev wrote:
> [ 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!

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.

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.)

A couple of approaches we could consider:

 1. 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.
 2. 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.
 3. 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.

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.

Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191009/e9ccf276/attachment.html>