[rfa/mips] Second go at vr5500 hilo hazard fix
Andrew Cagney
cagney@gnu.org
Thu Mar 25 22:14:00 GMT 2004
>>> 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
More information about the Gdb-patches
mailing list