Re: Avoid creating irreducible loops with threading jumps

[Jeffrey A Law <law at redhat dot com>]

On Sat, 2005-03-05 at 01:41 +0100, Steven Bosscher wrote:
> On Saturday 05 March 2005 00:32, Jeffrey A Law wrote:
> > On Fri, 2005-03-04 at 23:17 +0100, Steven Bosscher wrote:
> > > On Friday 04 March 2005 22:33, Jeffrey A Law wrote:
> > > > We're probably going to see a net slowdown of ~1% for this patch
> > > > as-is (and another percent for the next and last in this series).  I'll
> > > > be working on recovering more of the compile-time performance drops
> > > > once I install the final patch.
> > >
> > > This is the second 1% slowdown, with a third apparently coming up.  Many
> > > people (including you) have tried very hard to speed the compiler up, so
> > > losing 3% like this is a real shame.  Why can't these patches that slow
> > > the compiler down wait until you've found a way to win back some speed?
> >
> > What do you think I've been doing for the last couple months?  The
> > amount of downstream effects was, err, interesting.  Almost every
> > performance improving patch I've submitted in the last 2 months has
> > been from analyzing why things got slower with these patches.
> 
> But even without your patches those are stand-alone speedups, they
> don't have much to do with your patches.
Actually, they have a *LOT* to do with the DOM changes.  Why?  Because
the DOM changes hit those parts of the downstream compiler significantly
harder.  Nearly every one of those various changes was in response to
better jump threading exposing some kind of lameness in the backend
(often due to having more blocks) or support routines needing to be
called more often (cfg cleanups).

> 
> > I 
> > would place a sizable wager that my work over the last two months
> > has more than covered the 2-3% slowdown we'll see with the 3 DOM
> > related changes that have been queued up forever.
> 
> Winning 2-3% in one place does not justify losing 2-3% elsewhere.
I'm not saying it does.  But we have to be able to move forward
on this stuff or we've got little chance of making any progress
in eliminating or simplifying the RTL backends.

> 
> > I'll also note that without these changes we've got zero chance of
> > eliminating the jump following code in cse,
> 
> Most of the things CSE catches now are not jump following related
> at all.
There's still a goodly amount of things which are jump threading
related.


> Last time I looked, jump bypassing was mostly cleaning up the mess
> loop causes, so DOM is probably not going to help there.
It most certainly does.  With the improved jump threading that I've
got queued, the single biggest thing in the way of killing jump
bypassing is our insanely lame aliasing code.
  
> 
> > and the rtl jump threading code. 
> 
> It'd be nice to get rid of this, but replacing one slow pass with
> another is not a win.  And does catching those jump threads that we
> still miss at the tree level really buy us anything?  And I mean in
> terms of measurable improvements, not theoretically.
Yes it does.  You can see improvements.


> I'll just humbly note that you stone-walled patches in the past because
> you wanted to see performance numbers to see if some slowdown was worth
> it.
I'm sorry you see it this way.  I was not stonewalling -- I was trying
to avoid implementation ping-pong.   The path you had choosen was a
path we had already been down and decided against pursuing any further
due to compile time issues and a lack of gain.


>  I think there is reason to ask if your current patches are worth
> the slowdown they cause. 
It is my opinion, given 15+ years of working on GCC that if we do
not pursue this course of action that we have little chance of nailing
down the RTL issues.

And as I've stated several times before, the bulk of DOM as we know
it is likely going away.  ANd I believe that we will have the ability
to do incremental optimization after jump threading, which will
*drastically* reduce the cost of DOM.



>  In case you didn't notice, DOM is already by
> far the slowest tree pass, so "every freaking change" to DOM should be
> backed up by numbers, not void claims.
Depends on how you look at it.  DOM appears so bloody slow because it
is called so many damn times.  On top of that we know the iteration step
is costly, which is why we want to use a more sane algorithm for the
bulk of DOM's work.



>   But all you do us just continue
> claiming that the patches are "imparative" and "critical", without
> putting up any numbers.
I'm happy to post numbers.  I usually do if you were to go back and
look.  

jeff