This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]