Quite often I see a test quickly written to test some new feature (bug
fix, extension or optimization) that has a couple of functions to cover
various aspects of the feature, checked all together with a single
scan-tree-dump-times, scan-rtl-dump-times etc. check, using the expected
value for the target of the test writer.
Or worse, it's all packed into one giant function, with unpredictable
interactions between the different pieces of code. I think we have less
of those recently, but please don't interpret this post as a suggestion
to fall back to this practice.
Quite often it turns out that the feature applies only to some of the
functions / sites on some targets. The first reaction is often to
create multiple copies of the scan-*-dump-times stanza, with mutually
exclusive conditions for each copy, which might look harmless when there
are only two cases, but as more are added, it quickly turns into an
unmaintainable mess of lots dejagnu directives with complicated.
This can get even worse if different targets can get the compiler the
pattern multiple times for the same piece of source, like for
vectorization that is tried with different vectorization factors.
I think we should discuss what is best practice to address these
problems efficiently, and to preferably write new tests avoiding them
in the first place.
When each function has a single site per feature where success is given
if the pattern appears at least once, a straightforward solution that
has already been used a number of times is to split the test into
multiple smaller tests. The main disadvantages of this approach are
that a large set of small files can clutter the directory where they
appear, making it less maintainable, and that the compiler is invoked
more often, generally with the same set of include files read each time,
thus making the test runs slower.
Another approach would be to use source line numbers, where present and
distinctive, to add to the scan pattern to make it specific to the site
under concern. That should, for instance, work for vectorization
scan-tree-dump-times tests. The disadvantage of that approach is that
the tests become more brittle, as the line numbers would have to be
adjusted whenever the line numbers of the source site change, like when
new include files, dejagnu directives at the file start, or typedefs are
needed.
Maybe we could get the best of both worlds if we add a new dump option?
Say, if we make that option add the (for polymorphic languages like C++:
mangled) name of the current function to each dumped line that is
interesting to scan for. Or just every line, if that's simpler.
