Re: SPECfp2000 worsening

[Roger Sayle <roger at eyesopen dot com>]

Hi Dan,
> > I must admit that I haven't checked for potential spill effects in
> > the register allocator.  I was looking at aggressive jump bypassing
> > which is a control flow optimization (converting consecutive if-thens
> > into if-then-elses), which I believe shouldn't increase register
> > pressure or extend pseudo lifetimes beyond making basic blocks
> > larger.
> >
> You'd be surprised.
> If it can have an effect on scheduling, and if you are testing on a
> platform where pre-regalloc scheduling is run, it might happen to
> *completely* screw everything up.
> But even if it just makes BB's larger, it can make the local allocator
> handle more of the register allocation than it used to, and thus, could
> affect register allocation.
>
> I don't have spec2000, but if you could send me the before and after
> assembly, i'd love to analyze it (I realize it's probably very large).

I must admit that I don't have spec2000 either.  I normally develop
my patches testing on benchmarks like whetstone and bench++, and then
if they look promising, ask Andreas Jaeger to do the SPEC runs for me.

Without access to the SPEC sources much of the task is trying to guess
which interactions are causing the problems.  Yes, register allocation
could be a significant issue, but it appears that its the interaction
between LOOP and GCSE (more specifically cprop and jump bypassing) that
is the prime suspect.  Jeff Law has noticed similar poor interactions.

To make things harder, the SPEC suite are large programs, such as
176.gcc, so finding a single block of RTL that exhibits the problem
is often difficult.  The best I can do is guess from the type of
application which programming styles are positively/negatively affected.

Roger
--