This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: SPECfp2000 worsening
- From: Roger Sayle <roger at eyesopen dot com>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Fri, 20 Sep 2002 00:29:57 -0600 (MDT)
- Subject: Re: SPECfp2000 worsening
Hi Dan,
> Is this due to increased register pressure (from making more values
> live longer)? (IE do you see more spills when you make it more
> aggressive)? If so, -fnew-ra might help.
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.
However, I am a big fan of the new register allocator. I thought
I'd share one of my recent discoveries with you. One of the
benchmarks I use is Roy Longbottom's implementation of the classic
whetstone benchmark, whets.c.
On my athlon box, mainline CVS achieves 863 MWIPS, and running
GCSE after LOOP, instead of before, achieves 875 MWIPS (a 1.4%
improvement). However, Microsoft's MSVC 6.0 achives 1173 MWIPS.
As I was working on GCSE's control flow optimizations, I analyzed
loop N3 "if-then-else" to discover why MSVC scores 1181 MIPS,
whilst GCC gets only 581 MIPS despite many recent improvements.
The problem was poor register allocation with the loop counters
being spilled to the stack. Recompiling using "-fnew-ra" saw a
miraculous improvement in N3, 1202 MIPS, faster even than MSVC!
Unfortunately, despite the much better showing on N3, "-fnew-ra"
performs worse overall dropping to 782 Whetstone MWIPS. When I
attempted to analyse the loops that got worse, I discovered cutting
and pasting individual loops into a single function fixed the poor
allocation issues. "whetstone" (as coded in whets.c) is one large
function and I'm guessing this creates problems for the new register
allocator. A live range splitting issue?
Anyway, my investigation convinced me that the new register
allocator, though still a work in progress, is capable of
dramatic improvements. But unfortunately for the time being, it
appears to perform slightly worse than GCC's current allocator
on both SPEC2000 and whetstone.
Keep up the good work.
Roger
--