This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: Fix ll/sc for mips (take 3)
- From: cgd at broadcom dot com
- To: hjl at lucon dot org
- Cc: "Justin Carlson" <justinca at ri dot cmu dot edu>,"Daniel Jacobowitz" <dan at debian dot org>,"Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>,"Hiroyuki Machida" <machida at sm dot sony dot co dot jp>,libc-alpha at sources dot redhat dot com,linux-mips at oss dot sgi dot com,gcc at gcc dot gnu dot org
- Date: 03 Feb 2002 15:29:28 -0800
- Subject: Re: PATCH: Fix ll/sc for mips (take 3)
- References: <20020131231714.E32690@lucon.org><Pine.GSO.3.96.1020201124328.26449A-100000@delta.ds2.pg.gda.pl><20020201102943.A11146@lucon.org><20020201180126.A23740@nevyn.them.org><20020201151513.A15913@lucon.org><20020201222657.A13339@nevyn.them.org><1012676003.1563.6.camel@xyzzy.stargate.net><20020202120354.A1522@lucon.org> <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.
cgd