Re: gcc300 benchmarks slower than gcc295.3?

[Richard Henderson <rth at redhat dot com>]

On Thu, Jul 19, 2001 at 09:29:45AM -0700, Linus Torvalds wrote:
> What else is done after normal register allocation? It might still make it
> impossible to do other (better) tricks.

Very little.  Scheduling, basic block reordering, handling
of the thrice-damned fp stack.

> If I remember correctly, the K7 has more regular (but fewer) decoders,
> and is often decode limited. And my P4 test definitely implies that the P4
> doesn't like it - the main reason I can imagine probably being that it
> ends up doing the address arithmetic twice when you split the r-w-m into
> different operations.

In response to someone else's query, I've already verified that
the splitting is only done for PPro.

> Is the difference measurable on small benchmarks that fit in the L1
> icache, like dhrystone? Or is it measurable on real applications that have
> to load?

Sheesh, it was two years ago...  I remember it made a difference
for the Byte benchmark (which the customer inexplicably thought
was the bee's knees), but I thought we checked specint95 as well.

Ideally you'd only do the split in response to the scheduler saying
"I need some 1 uop insns to fill this decoder pipeline bubble."
That, however, is tricky.

If someone else wants to do benchmarking to verify the state of
the world at the moment, all you have to do to disable the splits
in question is to set x86_split_long_moves to 0 in i386.c.


r~