[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines

["lucier at math dot purdue dot edu" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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