This is the mail archive of the gcc-patches@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: * Re: remove 2nd DVCcodec time regression


> As I later mentioned, the i386 loop regressions weren't.  I've
> applied this to mainline; assuming it doesn't elicit failures
> somewhere, we can think about moving it to the branch.

It does show little regressions on SPEC2000 benchmarks in Specint (about 1.5
point, mostly because of twolf).  In specfp there are changes in both
directions.

Generally speaking, how long do we want to maitain this particular hunk of
code?  On the branch I've strengthned GCSE to move everything except for
libcalls (which I hope to die).  I know loop does contain some heuristics when
to move and when not, but this should be better handled by rematerization I
guess and if GCSE does all the moves earlier, I think there is no point to do
so.

But still, even with improved GCSE, some movables appears to be moving.  Any
idea why?

I guess GCSE refuses to do the move when loop may not iterate and the
expression may not be used.  With loop test duplication code this should not be
major problem and with frequency information we may try to teach it to do so.

Honza


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