I wonder if we'd do better to first add new match.pd patterns, one at a
time, with tests, and evaluating them along the way by looking at the
dumps
or .s files across many systems. Then when we think we've got the right
set, then look at what happens to those dumps/.s files if we make the
changes so that shorten_compare really just emits warnings.
As the shorten_compare function covers those transformations, I don't
see that this is something leading to something useful. As long as we
call shorten_compare on folding in FEs, we won't see those patterns in
ME that easy. And even more important is, that patterns getting
resolved if function gets invoked.
It will tell you what will be missed from a code generation standpoint if
you disable shorten_compare. And that is the best proxy we have for
performance regressions related to disabling shorten_compare.
ie, in a local tree, you disable shorten_compare. Then compare the code we
generate with and without shorten compare. Reduce to a simple testcase.
Resolve the issue with a match.pd pattern (most likely) and repeat the
process. In theory at each step the number of things to deeply investigate
should be diminishing while at the same time you're building match.pd
patterns and tests we can include in the testsuite. And each step is likely
a new patch in the patch series -- the final patch of which disables
shorten_compare.
It's a lot of work, but IMHO, it's necessary to help ensure we don't have
code generation regressions.