This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/59802] excessive compile time in RTL optimizers (loop unswitching, CPROP)
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 14 Jan 2014 13:24:01 +0000
- Subject: [Bug rtl-optimization/59802] excessive compile time in RTL optimizers (loop unswitching, CPROP)
- Auto-submitted: auto-generated
- References: <bug-59802-4 at http dot gcc dot gnu dot org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59802
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |steven at gcc dot gnu.org
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to David Binderman from comment #3)
> (In reply to Richard Biener from comment #2)
> > Oh, did you configure with --enable-checking=release for 4.9? (I did)
>
> No, I used --enable-checking=yes.
That makes the comparison to 4.8 invalid (uses --enable-checking=release
by default).
Btw, callgrind shows that compile-time is dominated by
bitmap_intersection_of_preds (and bitmap_ior_and_compl),
called from lcm.c:compute_available. LCM works with
sbitmaps which can be very expensive for large functions.
tree PRE uses regular bitmaps, but it seems that LCM can
end up using the full bitmap via returning bitmap_ones
from bitmap_intersection_of_preds (for a block with no preds).
It seems compute_available doesn't use optimal iteration order
and that explicitely representing the maximum set instead of
handling unvisited preds makes things more expensive (need to
use sbitmaps).
Iterating in inverted postorder gets me
CPROP : 2.13 ( 5%) usr 0.06 (10%) sys 2.20 ( 5%) wall
4444 kB ( 2%) ggc
with no changes in generated code ...