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 #13 from law at redhat dot com  2005-10-31 23:36 -------
> Subject: Re:  [4.1 Regression] Slowdown of the
>         bresenham line drawing by roughly 20%
> 
> On Mon, 2005-10-31 at 23:25 +0000, hubicka at ucw dot cz wrote:
> 
> > 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 how do you propose to change that without simply removing the
> reassociation code from our tree optimizers?
> 
> 
> >  (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.
> It is definitely reassociation + simplification (reassociation without
> simplification is, err, dumb) -- the code was lifted from cse.c and
> transformed to work on trees in SSA form (and stuck into DOM as we
> didn't have a better place to put it a couple years ago :(. 

Hmm, perhaps restricting the reassociation + simplification into case
where it kills last use of the intermediate result?  
I can definitly think of testcases where such heuristic would hurt, but
some experimentation with it would be useful...
I've looked what the other compilers are doing and except for ICC that
manages to get even worse code than we do by completely broken if
conversion all seems to get across that correctly...

Honza


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