Re: SPECfp2000 worsening

[Jeff Law <law at porcupine dot slc dot redhat dot com>]

In message <Pine.LNX.4.33.0209192149120.9755-100000@www.eyesopen.com>, Roger Sa
yle writes:
 >
 >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.
One experiment I could recommend would be to move jump bypassing so that
it happened after loop.

When I was looking at having loop begin/end notes created by the loop
optimizer instead of relying on those created by the front-ends, I
consistently saw the jump bypassing code mucking up loop nests -- bad
enough that cfg based loop discovery would lose nesting information.
I didn't dive deep enough into this to see if something like interval
analysis would discover the proper nesting.


So an interesting experiment would be to have the normal gcse run before
loop and one with jump bypassing after loop.

I also encountered a few cases where other gcse actions would result in
inaccurate BEGIN/END notes for loops -- in rare cases gcse can create
insns which are part of the loop, but which are not enclosed by the
loop notes.  This is bad -- and may potentially result in incorrect code.
This argues that I should complete my code to rebuild the loop notes and
get it checked in :-)

 >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.
Note that placement of the begin/end notes is indeed easy.  Placement
of a loop_cont note is exceedingly hard -- it'd be a hell of a lot
better if we removed the dependency on loop_cont notes.  But an 
interm step may be to rebuild the begin/end notes when the loop
optimizer starts.

jeff