[Bug middle-end/23181] [4.1 Regression] Slowdown of the bresenham line drawing by roughly 20%

["law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #14 from law at redhat dot com  2005-11-01 22:24 -------
Subject: Re:  [4.1 Regression] Slowdown of the
        bresenham line drawing by roughly 20%

On Mon, 2005-10-31 at 04:36 +0000, mmitchel at gcc dot gnu dot org
wrote:
> 
> ------- Comment #9 from mmitchel at gcc dot gnu dot org  2005-10-31 04:36 -------
> So, Jeff, is it your opinion that this is just an inevitable case of
> optimizers-aren't-perfect?  If so, would you please just close this PR?
I think it's still unclear at this point what the best course of
action will ultimately be.  Doubly so since it still actually unclear
what code people actually want for the testcase :-)

We've got a series of events that leads to bad code for this testcase,
but all the optimizers do doing basically what I would expect them to
do.

This code is scheduled for some work as part of cleaning up DOM and
depending on which direction we ultimately take with reassociation
we may (or may not) be able to look into ways to throttle it.

One possibility for throttling reassociation is to only do it when
we'll be able to eliminate the parent statement.  By doing so we'd
effectively turn reassociation into tree-combine+simplification
(which is all it is right now anyway).

However, I don't expect that to happen in time for 4.1.  It's fairly
simple to convert the cleanups queued for the simplify-dom branch to
work in that manner, but I haven't gotten around to analyzing whether
or not that throttling is generally a good idea or not.  The first
step is just to get this non-DOM stuff out of DOM.

It's also the case that Daniel has a completely new reassociation pass
which also needs an evaluation.  The reassociation currently done in
DOM is pretty simplistic, there are certainly better approaches and
algorithms.  Unfortunately, everything I've read about reassociation
has indicated that sometimes it plain loses, but that overall it's
a win.  So we could be fighting this class of problems for a long
logn time :(

jeff


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23181