limit code expansion on ifcvt - bbro too?

[tm]

On Tue, 19 Nov 2002, Richard Henderson wrote:

> On Mon, Nov 18, 2002 at 03:36:20PM -0800, tm wrote:
> > Is maybe_hot_bb_p usable for limiting code expansion on BBRO as well?
> > If so, I'll try to submit a patch for it.
> 
> Instead of spending so much effort trying to selectively disable
> parts of BBRO, why don't you come up with a placement algorithm
> that minimizes (1) branches or (2) sum of branch insn sizes.
> 
> It shouldn't be _that_ hard.
> 
> 
> r~

The problem is that BBRO only seems applicable to processors whith the
following characteristics:

1) High branch penalty

2) Weak/no branch prediction logic

Most CISC microcoded processors (68000, H8, etc) require the same number
of clocks for branch taken/not taken, so #1 does not apply.

Most recent microprocessors have deeper pipelines so #1 does apply, but
they also have pretty good branch prediction logic which dynamically does
a better job than bbro's static analysis.

The only processors I can think of offhand which benefit from this
optimization are:

80386
80486
Pentium
MIPS (some embedded versions deep pipes and minimal branch prediction)
Alpha (21064, but probably not anything else)

The processors which probably don't benefit from this are:

Pentium Pro and above
1750a
a29k
arc
arm
avr
c4x
clipper
convex
cris
d30v
dsp16xx
elxsi
fr30
frv
fx80
gmicro
h8300
i370
i860
i960
m32r
m68hc11
m68k
m88k
mcore
mn10200
mn10300
ns32k
pdp11
pj
pyr
rs6000
spur
stormy16
tahoe
v850
vax
we32k
xtensa

Ones I don't know enough about:

pa
sparc

Toshi