[Top] [All Lists]

Re: PATCH: Fix ll/sc for mips (take 3)

Subject: Re: PATCH: Fix ll/sc for mips (take 3)
Date: 03 Feb 2002 15:29:28 -0800
Cc: "Justin Carlson" <>, "Daniel Jacobowitz" <>, "Maciej W. Rozycki" <>, "Hiroyuki Machida" <>,,,
In-reply-to:'s message of "Sat, 2 Feb 2002 20:04:10 +0000 (UTC)"
References: <> <> <> <> <> <> <> <> <mailpost.1012680250.7159@news-sj1-1>
[ Hi Justin, enjoying winter in pgh?  8-]

At Sat, 2 Feb 2002 20:04:10 +0000 (UTC), "H . J . Lu" wrote:
> Does everyone agree with this? If yes, I can make a patch not to use
> branch likely. But on the other hand, "gcc -mips2" will generate code
> using branch likely. If branch likely doesn't buy you anything, 
> shouldn't we change gcc not to generate branch likely instructions?

Branch-likely instructions probably _do_ buy you something (at least,
slightly less code size) on some CPUs, probably even some CPUs which
are still being produced.

FYI, somebody, i think it was Mike Stump, submitted a patch to add a
flag to disable branch-likely instructions N months ago.  It was
discussed a little bit, not AFAIK nothing was ever done with it.

To quote the MIPS32 instruction set document from the MIPS web site:

> Programming Notes:
> [ ... ]
> Software is strongly encouraged to avoid the use of the Branch
> Likely instructions, as they will be removed from a future revision
> of the MIPS Architecture.
> Some implementations always predict the branch will be taken, so
> there is a significant penalty if the branch is not taken. Software
> should only use this instruction when there is a very high
> probability (98% or more) that the branch will be taken. If the
> branch is not likely to be taken or if the probability of a taken
> branch is unknown, software is encouraged to use the BGEZAL
> instruction instead.

If you have a sufficiently high static likelyhood of branch-taken, it
may well be worthwhile to use branch-likely even on MIPS32/MIPS64 if
it'll save you code space, or if you can determine that not clogging
up your branch history / predictor buffers makes your code run
faster.  However, it should definitely not be the default.

Anyway, from where I sit, this should be resolved like:

* -mips1 - -mips5 should generate them by default (for
  strongly-predicted branches), -mips32 & -mips64 should not.  (modify
  that for your favorite flag names, -march or whatever.  8-)

* There should be flags to override the defaults either way, so you
  could say -mips2 -mno-branch-likely, or -mips32 -mbranch-likely.


<Prev in Thread] Current Thread [Next in Thread>