This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/26854] Inordinate compile times on large routines
- From: "dberlin at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 18 Jan 2011 14:54:58 +0000
- Subject: [Bug tree-optimization/26854] Inordinate compile times on large routines
- Auto-submitted: auto-generated
- References: <bug-26854-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #123 from Daniel Berlin <dberlin at gcc dot gnu.org> 2011-01-18 14:54:33 UTC ---
On Tue, Jan 18, 2011 at 9:49 AM, hubicka at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
>
> Jan Hubicka <hubicka at gcc dot gnu.org> changed:
>
>      What  Â|Removed           |Added
> ----------------------------------------------------------------------------
> Â Â Â Â Â Â Â Â CC| Â Â Â Â Â Â Â Â Â Â Â Â Â Â|hubicka at gcc dot gnu.org
>
> --- Comment #122 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-01-18 14:48:32 UTC ---
> oprofiling shows that 50% of parsing time is in decl_jump_unsafe that is C
> frontend thingy to output some sort of warnings on gotos to VLAs. ÂThis can
> probably be solved quite easilly.
>
> Later we get (at -O2 all.i)
> 83417 Â Â17.0179 Âcc1 Â Â Â Â Â Â Â Â Â Â Âdominated_by_p
> 75164 Â Â15.3342 Âcc1 Â Â Â Â Â Â Â Â Â Â Âbitmap_equal_p
> 38134 Â Â 7.7797 Âcc1 Â Â Â Â Â Â Â Â Â Â Âbitmap_set_bit
> 26144 Â Â 5.3336 Âcc1 Â Â Â Â Â Â Â Â Â Â Âbitmap_ior_into
> 21031 Â Â 4.2905 Âcc1 Â Â Â Â Â Â Â Â Â Â Âdecl_jump_unsafe
> 16142 Â Â 3.2931 Âcc1 Â Â Â Â Â Â Â Â Â Â Âregister_new_assert_for.isra.42
> 12713 Â Â 2.5936 Âcc1 Â Â Â Â Â Â Â Â Â Â Âbitmap_elt_insert_after
> 11136 Â Â 2.2719 Âcc1 Â Â Â Â Â Â Â Â Â Â Âsbitmap_a_or_b
> 10625 Â Â 2.1676 Âcc1 Â Â Â Â Â Â Â Â Â Â Âet_splay
> 10059 Â Â 2.0521 Âcc1 Â Â Â Â Â Â Â Â Â Â Âwalk_dominator_tree
> 6775 Â Â Â1.3822 Âcc1 Â Â Â Â Â Â Â Â Â Â Âdse_enter_block
> 5952 Â Â Â1.2143 Âcc1 Â Â Â Â Â Â Â Â Â Â Âbitmap_bit_p
This looks suspiciously like it's not using the DFS numbers