Re: [PATCH] Disable CSE skip-blocks (fwd)

[Roger Sayle <roger at eyesopen dot com>]

Doh!  I mispelt gcc-patches in my original attempt! ...

---------- Forwarded message ----------
From: Roger Sayle <roger@eyesopen.com>
To: Steven Bosscher <stevenb.gcc@gmail.com>,
     Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
Cc: Paolo Bonzini <paolo.bonzini@lu.unisi.ch>, gcc-pacthes@gcc.gnu.org,
     Mark Mitchell <mark@codesourcery.com>
Subject: Re: [PATCH] Disable CSE skip-blocks
Date: Sun, 29 Oct 2006 09:20:02 -0700 (MST)
Message-ID: <Pine.LNX.4.44.0610290846550.32359-100000@www.eyesopen.com>
In-Reply-To: <200610291435.32917.steven@gcc.gnu.org>


Hi Steven, Richard and Paolo,

On Sun, 29 Oct 2006, Steven Bosscher wrote:
>
> 	* opts.c (decode_options): Disable CSE skip blocks.

If it's Ok with Richard, I'd like to make an executive decision on
this one, and approve of Steven's series of CSE clean-ups in principle.

As middle-end maintainer, I do like what Steven (and Paolo) are
trying to achieve with this pass.  Indeed, everyone agrees that CSE
is a critical RTL optimization that has needed a significant clean-up
and reorganization for a long time.  That different people have
different views on how this can be done best, has only slowed down
the process and frustrated contributors.

Indeed, Steven B's plan was articulated over two years ago in
http://gcc.gnu.org/ml/gcc/2004-08/msg01620.html, if not even
earlier.  However, real patch contributions carry more weight
than opinion.  Indeed, much of Steven B's plan, for example, to
make things work with CFG layout mode, should be common to any
re-write.


I should also say a little about benchmarking.  I also agree with
Steven that his plan should ultimately result in a net win for the
RTL optimizers.  I have faith than when complete the resulting
objects will be smaller and faster.  It doesn't make much sense
to enquire about "SPEC with -fno-cse-skip-blocks" because it may
be unreasonable to expect all the intermediate steps to be monotonic
improvements.  If anything is to get done, we need to take a little
risk once in a while.  Indeed early stage 1 is when we should take
those risks.

The nice thing is that we have bugzilla to track regressions.  We
can fix missed-optimization regressions from now all the way through
stage 3 of 4.3's release cycle.  However, I'd expect 4.3 to benchmark
better than 4.2 once Steven is through.

Taking this one change as an example.  It's not the end of the world,
if we ultimately discover that we really do need to follow blocks as
we currently do, incurring the terrible time complexity.  Adding this
functionality back in after a significant clean-up, for example using
CFG-layout mode, with better back-tracking etc... will likely be much
better than what we currently have, based on our aging infrastructure.
Not that I imagine/anticipate this is even remotely likely, but we have
time to move forward, and dapat and address issues as we progress.

We still have regressions from moving to tree-ssa, but no one doubts
the benefits far outweigh the minor loses.


I'd like to appove this patch, but won't do so if Richard still
objects strongly.  He's officially a global maintainer and author
of much of the original CSE code.  Hopefully, my arguments above
will convince him, but if not, we can always consult the SC.


Roger
--