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.

Reply via email to