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

[Nigel Stephens <nigel at mips dot com>]

Richard Sandiford wrote:
> 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_4KC,
> >   PROCESSOR_4KP,
> >   PROCESSOR_5KC,
> >   PROCESSOR_5KF,
> >   PROCESSOR_24KC,
> >   PROCESSOR_24KF2_1,
> >   PROCESSOR_24KF1_1,
> >   PROCESSOR_74KC,
> >   PROCESSOR_74KF2_1,
> >   PROCESSOR_74KF1_1,
> >   PROCESSOR_74KF3_2,
> >   PROCESSOR_M4K,
> >     
>
> -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.
>   

Hmm.  I don't think that -mtune is overriding -march. The mip32 
architecture spec defines the branch-likely instruction, so 
-march=mips32r2 is allowed to generate a branch-likely -- it's just 
CPU-dependent whether it is efficient to do so or not, with the default 
being to assume that it isn't. Hence I thought that it would be a -mtune 
issue rather than -march, i.e.:

--march=mips32r2
 Generate generic mips32r2 code, without branch-likely.

--march=mips32r2 -mtune=24ke
 Generate generic mips32r2 code, with branch-likely.

-march=24ke
 Generate 24KE specific code: mips32r2 + DSP ASE + branch-likely.

> 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.
>
>   

Branch likely should not be used for the 20K (and 25K), unless the 
branch is >~95% likely to be taken.

Nigel