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
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
