------- Comment #15 from hubicka at ucw dot cz 2005-11-02 14:32 ------- Subject: Re: [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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23181
