x86 branch cost

[Marek Michalkiewicz <marekm at t19 dot ds dot pwr dot wroc dot pl>]

I've just looked at the effect of this patch (still being reviewed):

http://gcc.gnu.org/ml/gcc-patches/2000-05/msg00480.html

on x86 code generated for int / 2 divide (no change for divide
by higher powers of 2).  (The patch looks like a big win on small
targets, where shifts by many bits are expensive, such as AVR.)

The default x86 branch cost is 1 for all CPUs.  With this patch,
this results in a bit smaller but slower code, using a branch
(which the compiler considers cheaper - constant shift cost is 2).
Now compiling with -mbranch-cost=2 results in the same (larger and
faster) code as without the patch.  Which brings the question:

Should x86 branch cost be changed to 2 when not optimizing for size?

My basic understanding of the x86 architecture is that it has to
flush its prefetch queue if the branch is taken, which is slow.
I don't know the precise details of the latest and greatest CPUs
(I know they do some magic optimizations :), but my tests (done on
a Pentium III, but with no special CPU options) seem to indicate
this is still true (it is faster to do more shifts but no branches).
There may be other cases I haven't tested where branch cost of 1 is
a win, but I suspect this is just a default remaining to be tuned -
processor_target_table[] makes it possible to specify different
values for different CPUs, but they are currently all the same (1).

I ask about it here because the patch might be rejected for making x86
code slower, which I think could be fixed by increasing branch cost,
unless that would make something else worse.  Could some experienced
x86 hacker take a look at it?  Without the patch, there doesn't seem
to be a way for a target to indicate that int / 2 is better done using
a branch (test the sign bit) instead of a shift (sign bit -> bit 0).

Thanks,
Marek