This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: SPECfp2000 worsening
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: Toon Moene <toon at moene dot indiv dot nluug dot nl>,Paolo Carlini <pcarlini at unitus dot it>, <gcc at gcc dot gnu dot org>,Andreas Jaeger <aj at suse dot de>, Jeff Law <law at redhat dot com>
- Date: Fri, 20 Sep 2002 01:22:38 -0400 (EDT)
- Subject: Re: SPECfp2000 worsening
On Thu, 19 Sep 2002, Roger Sayle wrote:
>
> 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.
>
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.
>
> My biggest concern is that GCSE is expensive (a hot spot in some
> profiles) and running it twice is not be undertaken lightly.
Unfortunately, when it's a hot spot, it's usually the computation
of local properties. At least, that's what i remember from staring at
profiles of it. If it was the LCM data flow iteration, a better
iteration strategy would help.
> 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.
CSE in it's current form does value numbering (it really should be
renamed).
So this really might not be a good idea.
> GCC's
> CSE is also an expensive hot spot, so removing it may offset some of
> the expense of a second GCSE.