Re: MIPS branch-likely not tied to branch probability?

[Richard Sandiford <rdsandiford at googlemail dot com>]

Paul Koning <paul_koning@dell.com> writes:
> It looks like the machinery that picks MIPS branch-likely instructions
> (on processors that don't object to them) is driven purely by their
> delay slot annul properties and not at all by branch probability.

Unfortunately, reorg.c is very old code that is effectively in deep
maintainance mode.  It has many problems: it doesn't use proper liveness
information (instead using rather expensive and less accurate estimates
based on old block boundaries), it operates after normal scheduling,
so can disrupt the pipeline.  Etc.

Bernd has another approach for C6X that might be worthwhile on
other targets too.  I'm planning to try it on MIPS at some point.

> 1. Assuming it doesn't matter to the delay slot fill logic, does GCC
> offer a way for one branch instruction to be picked over another based
> on branch probability calculations?  I looked a bit and didn't see how
> to do that.

reorg.c does try to use REG_BR_PROB notes.

> 2. In the delay slot fill machinery (reorg.c), I don't see how a
> target can supply hooks to adjust the picking of one branch over
> another.  In other words, if the architecture has branch-likely that
> has annul, but that instruction should not be used in a particular
> spot because the branch is in fact NOT likely, how would one do that?

This isn't something that should be handled by target hooks.  The way
that we record branch probabilities is target-independent, and reorg.c
already knows whether the target has both annulled and non-annulled
branches.

Richard