Re: Mainline is now regression and documentation fixes only

[Richard Sandiford <rsandifo at nildram dot co dot uk>]

Richard Guenther <rguenther@suse.de> writes:
> On Wed, 23 Jan 2008, Richard Sandiford wrote:
>> Please could someone have a look at:
>> 
>> http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00415.html
>> 
>> It fixes a pretty important regression for MIPS GNU/Linux, and if
>> the patch isn't acceptable, I'd like to know soon so that I have
>> time to implement whatever alternative we decide on.
>
> It doesn't mention a PR though you say its an important regression.

FWIW, I didn't open one because it was me who identified the problem.
Since I did that before stage 3, and posted the patch before stage 3,
there didn't seem much point opening a PR too.

I can open one if you like though.  Should I make a point of doing
that for other patches too (like the CTZ thing I posted earlier today)?

> I also see that it doesn't include a single testcase.

It's a little tricky to test for.  On GNU/Linux it's a performance
regression.  At the moment, we have all the right instructions, but
we're using the result of the wrong instruction in certain places.
A simple regexp is not in itself a good test.  I suppose we could
just check that all loads are to $25, but I believe that the same
problem could occur even if the patterns themselves force that.
It also wouldn't handle cases where we load a value into $25
first and then copy it to a call-saved register (rather than
the other way around).

I think this is similar to the way that, for example, not all fixes
for SPEC performance regressions need testcases.  We have something
that we've needed to do for the last few releases but which (unless
someone tells me otherwise) cannot currently be represented properly
when using the DF machinery.  (Through no fault of the machinery's.)
If that's true, there's a demonstrable need for a change.  Given that
a regexp testcase wasn't really sufficient, I instead tried to compare
before and after code as described in the message, using custom scripts
to help out.  And in this scenario, it's clearly the MIPS maintainer's
responsibility to keep tabs on this.  No-one else gets blamed for
breaking it.

(ISTR a few years back seeing the IRIX dynamic resolver crash when called
twice for the same function, so it might show up as an execution problem
on certain versions of IRIX.  The version I used was quite old though,
and I don't have access to it any more.)

Richard