This is the mail archive of the gcc-bugs@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: [Bug middle-end/23181] [4.1 Regression] Slowdown of the bresenham line drawing by roughly 20%


> 
> 
> ------- Comment #11 from law at redhat dot com  2005-10-31 23:18 -------
> Subject: Re:  [4.1 Regression] Slowdown of the
>         bresenham line drawing by roughly 20%
> 
> On Mon, 2005-10-31 at 20:55 +0000, hubicka at gcc dot gnu dot org wrote:
> > 
> > ------- Comment #10 from hubicka at gcc dot gnu dot org  2005-10-31 20:55 -------
> > Jeff, you missed the propagation DOM makes that hurts register allocation
> > indpeendently on whether code sinking does or does not it's job.
> > In reality code sinking (that appeared in GCC after I reported the bug)
> > improves the code as we create conditional move:
> The complaint earlier in the PR indicates the problem is too many
> jumps in the code (comment #6).  My analysis was focused on that
> specific issue -- and for that issue DOM isn't the culprit.  The
> culprits for that issue are the combination of edge splitting and
> code sinking.
> 
> So according to you, the issue here isn't the jumps, but the lack 
> of a conditional move?  Right?

See comment #5.  The fact that we ended up with more jumps was just the
fact that dom transforms it into more dificult to optimize form (and we
didn't have code sinking at that moment, there is also mentioned that
code sinking would help here). 
It is not CSE nor reassociation.  It is combining of the two increments
done interesting way so we can't really undo it later.

Honza
> 
> 
> I'll also note that the propagation done by DOM is exactly the same
> kind of thing that CSE is going to do and likely the same thing that
> Daniel's reassociation pass is likely to do (I haven't looked at the
> latter in detail, so maybe somehow it avoids the problem).   It may
> be the case that this can't be fixed and would be a classic problem
> of optimizations sometimes doing bad things.
> 
> 
> 
> jeff
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23181


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