Re: SPECfp2000 worsening

[Roger Sayle <roger at eyesopen dot com>]

Hi Toon,

> ... I want to wait until Roger Sayle completes his
> promised reversal of the GCSE and LOOP optimisation pass.
>
> If GCSE really makes it hard for LOOP to recognise opportunities for
> optimisation, it might be best to put it after LOOP; after that we
> would have to re-assess the situation from there.

I thought I'd keep you informed of how things are progressing.
The short answer is not great.  Andreas has been benchmarking a
number of patches for me, and almost everything I've tried so
far makes SPECint2000 worse!

Simply moving GCSE after LOOP improves SPECfp2000 slightly (+1.5%)
but makes SPECint2000 slightly worse (-0.5%), but the biggest loser
was 176.gcc itself.  This makes sense as the FP programs rely on
good loop optimizations, whereas GCC and most integer programs
prefer GCSE prior to LOOP.

I've also tried in combination with two other patches that
should in theory have made significant improvements to GCSE
(aggressive jump bypassing and implict sets, "if (x == 4)...").
Strangely, the stronger I make GCSE the worse the overall SPEC
scores, despite impressive improvements to 176.gcc.  Many of
the optimizations more than pay for themselves, reducing the
GCC bootstrap time when performing the additional optimizations.


However, I currently see three possible ways forward.

The first is to use GCC's loop notes to disable modifications to
the control flow graph that would interfere with the loop optimization
pass.  i.e. by checking for NOTE_INSN_LOOP_BEG notes before a label,
we can disable the cprop and jump bypassing optimizations that could
create irreducible loops, etc...

The second is to run GCSE both before and after LOOP.  The initial
GCSE run can be done with modify_jumps set to zero, and the later
GCSE run with modify_jumps set to one.  This fits in with the model
in conventional compiler texts, such as Muchnick, where GCSE is done
before loop optimizations, but control flow optimizations are performed
afterwards.  Because GCC's control flow optimizations make use of PRE,
we perform them simultaneously, but these could/should be separated.

My biggest concern is that GCSE is expensive (a hot spot in some
profiles) and running it twice is not be undertaken lightly. However,
we can lower max_gcse_passes and balance the number of before and
after iterations.  The other trade-off is that Jan's recent addition
to do local CSE in GCSE and my patch inform PRE of implicit sets,
should eventually allow GCC's current CSE pass to be removed.  GCC's
CSE is also an expensive hot spot, so removing it may offset some of
the expense of a second GCSE.

Finally, if all else fails, we'll need a CFG based loop optimizer.
This is already being worked on on the cfg-branch.  An intermediate
step proposed by Jeff Law, would be a CFG-based loop note insertion
pass that would analyse the CFG, correctly place the LOOP notes
where needed and then run the existing strength-reduction et al.


I hope this explains some of my current thinking.  My guess is that
we may need some combination of all three solutions.  To summarise,
I have patches that can completely reverse the recent degradations
in SPECfp2000.  The problems is to get around their other adverse
side-effects.

I'd really appreciate comments from anyone else whose tried banging
their heads on this; RTH, Jan, Jeff...  Many thanks again to Andreas.

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833