------- Comment #86 from lucier at math dot purdue dot edu 2009-02-13 15:40
-------
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
It's unfortunate that the discussion from 39157 will be somewhat hard to
find now that that bug is closed.
Steven wrote in a comment for 39157:
It's not like there will not be any loop invariant code motion
(LICM) at all anymore if the RTL LICM pass is disabled. There
is an LICM pass on GIMPLE, and there is also PRE for GIMPLE (and
lazy code motion for RTL but I think it disables itself for your
test case).
The RTL LICM pass mostly cleans up after expand, i.e. moves
things that are not exposed in GIMPLE. This is mostly just
address calculations.
The loop in _num.i that I mentioned in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39157#c19
is the loop in PR 33928 that is no longer fully optimized after Paolo
(and you, I guess, your name is on the patch) added PRE and disabled
some optimizations in CSE, and what is no longer optimized in that loop
are address calculations. I don't know whether those address
calculations fall under LICM, the only point I'm trying to make right
now is that address calculations are no longer optimized as much as they
were before
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118475
and address calculations are an important class of calculations to
optimize.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
