scan-*-dump-times across multiple functions considered harmful

[Joern Wolfgang Rennecke]

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.