Re: passing branch prediction information to asm output

[Jeffrey A Law <law at cygnus dot com>]

  In message <199709230739.DAA01067@jenolan.rutgers.edu>you write:
  > The REG_BR_PRED I added is not static always.  If REG_BR_PROB notes
  > were created in the RTL based upon gcov information, the REG_BR_PRED
  > flags will be set based upon them.
Oh.  I must have missed that.  Still not sure we want/need separate
notes, but it's late and I want to sleep :-)

  >    You should add some docs to the gcc manual for the new notes --
  >    make sure to mention when the new predict note is valid.
  > 
  > Sure, I'll do this tomorrow.
Thanks.


  > On certain platforms, in particular those which do dbr scheduling, the
  > dbr pass will change a decent percentage of the predictions by the
  > time it is done.  So in the cases where this does happen, you made
  > decisions based upon information which is now completely different.
Absolutely.  However, it's an order of magnitude easier to do basic
block layout to avoid mis-predicted branches before dbranch scheduling.

I can even see in the future a bit that says "this conditional
branch shouldn't be reversed" because we've done block layout to
avoid mis-predicted branches.  Or maybe we find that reorg doesn't
reverse enough of the ones we care about to make it worth the
effort to keep it from happening.

  > I have thought now and again about a "super scheduler" which knew how
  > to do the dbr stuff as well as what it does already.  And really, when
  > we in the future model superscalar's more accurately, such a thing
  > will almost be of necessity to get it right.
Blue sky, IMHO.  This was discussed years ago, mostly in the context
of reorg stealing insns from the middle of a critical block and
scrogging the schedule or avoiding conflicts for insns in the
delay slot of a branch back to the top of a loop.  (they can
have load/use stalls for example).

If we can come up with some heuristics to prevent this from happening
most of the time I'd be happy.

And, I think you'll find delay slots are on their way out as a key
component to good performance; the only real reason to keep them in
high performance processors is for compatability reasons.  As such
it's not clear if we're already past the point of diminishing
returns for improvements to reorg.

Perfect schedules are an "NP-hard" problem if I remember correctly.
Just something to keep in mind.

jeff