Re: [rfa/mips] Second go at vr5500 hilo hazard fix

[Andrew Cagney <cagney@gnu.org>]

>>>     As for having to tag each individual entry in the .igen file with an
>>>     explicit CPU. Yes, that sux. However, I also believe that it has
>>>     significantly reduced the overall error rate (no more breaking one
>>>     target by editing another) and that benefit vastly outweighs the short
>>>     term pain.
> 
> 
> I still take issue with the latter ("short term pain"), for such
> additions have to stay in for the life of support for the arch in the
> simulator, which *should* be quite long term.

Look at it this way, if the igen mechanism is used, gcc is able to 
eliminate everything :-)

If there's another way of achieving the same effect, I'm interested.

>>> But that was exactly what Andrew objected to:
> 
> 
> And he and I (strongly, IMO) disagreed at that time.  (IIRC, I think I
> mentioned at the time that the right solution to this is better
> testing.  I still think that's true.)
> 
> Of course, in August of last year, (unprompted by me!) he decided to
> stop being MIPS co-maintainer.  So, at this point, I'm the approval
> authority, and I like my style of patch most.  8-)
> 
> I would like to see it augmented to include some test code (now that
> there's a prelim test framework for mips, with what, 1 test? 8-), but
> as long as you commit to actually doing that I'm OK with it waiting a
> little bit.

Your call.

Andrew