[Patch] MIPS: Fix PR33479 Broken atomic memory primitives.

Richard Sandiford rsandifo@nildram.co.uk
Wed Sep 26 17:18:00 GMT 2007

Nigel Stephens <nigel@mips.com> writes:
> It is certainly correct that we should not generate branch likely 
> instructions by default for ISAs which deprecate them. However on most 
> MIPS Technologies CPUs a branch likely incurs no penalty and use of it 
> results in faster and smaller code. So while "untuned" mips32/mips64 
> code should not contain branch likelies, IMHO the following values of 
> mips_tune should enable branch likely:
>   PROCESSOR_24KF2_1,
>   PROCESSOR_24KF1_1,
>   PROCESSOR_74KF2_1,
>   PROCESSOR_74KF1_1,
>   PROCESSOR_74KF3_2,

-mtune options shouldn't override decisions based on -march, so either
we should forget about this whole deprecation thing, or we should exclude
the above values of -march (rather than -mtune).  The latter option is
justified because "-march=4kc" represents a fixed architecture, whereas
presumably the point of honouring the deprecation is so that -march=mips32
stands more chance of working with all future revisions of the ISA.

However, from what Ralf says about the deprecation only being on paper,
and from what you say about the instructions producing "smaller and
faster code" even for MTI's own implementations, I tend to prefer the
former option.  If MTI ever do decide to remove the instructions in
revision X, users can just use -march=mips32rX or -march=mips64rX for
gccs that support those options, and -mno-branch-likely for gccs that
don't.  Removing the deprecation is also simpler and easier to document
than adding more -march-based tests.

If there are specific processors that don't benefit from branch-likely
instructions, we should add them to the existing !TUNE_SB1 and
!TUNE_MIPS5500 checks regardless of whether we keep the deprecation.


More information about the Gcc-patches mailing list