This is the mail archive of the
mailing list for the GCC project.
Re: head: MIPS: Complete the R4000 multiply/shift errata workaround
On Thu, 19 Feb 2004 firstname.lastname@example.org wrote:
> > 1. Differentiate between R4000 and R4400 as the latter doesn't suffer from
> > the problem.
> > 2. Add an option to toggle the workaround regardless of the processor
> > selected.
> FWIW, from my perspective (not a maintainer 8-), I think this is not a
> "possible" improvement, it's a necessary improvement.
Well, the current code enables the parts of the workaround already
present for the R4000 only. So at the first shot I've preserved this
property, not to complicate the changes further. As I imply in the mail,
I see no problem with doing such improvements gradually.
> GCC's MIPS back-end should be capable of generating 'safe' code that
> runs on a given minimum ISA level, for any processor that it knows
> about fixes for, e.g.
> -mips3 -mfix-r4000 -mfix-sb1 -mfix-...
I agree with that. Especially as these particular errata are documented
to trigger for 32-bit operations as well (I couldn't reproduce that,
though), so there may be a need to enable this even for code generated for
I'm not sure if "-mfix-r4000" is the right name, though, as that would
imply working around all problems with the processor. And there is
another problem that is common to both the R4000 and the R4400 (I have a
patch in preparation, but it's not ready yet). I think these options
should operate on disjunctive sets of adjustments to code generation, not
to lead to weird configurations like one that would happen with
"-mfix-r4000 -mno-fix-r4400" in this case.
> Whether -mfix-r4000 should be the default in a given configuration is
> not something I'm qualified to speak about, but it should definitely
> be a flag that can be enabled/disabled seperately from general arch =
> r4000 code generation.
I think the Linux kernel configuration would be cleaner with this
arrangement, too. There is initial support for this workaround in the
64-bit kernel configuration present already.
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+ e-mail: email@example.com, PGP key available +