For datem.f from sixtrack, i get loop invariant motion : 23.03 (17%) usr 0.05 ( 7%) sys 23.82 (16%) wall loop iv optimization : 21.03 (15%) usr 0.05 (7%) sys 22.13 (16%) walll On struct-aliasing, which has vuse bypassing enabled (and thus enables more optimization), the situation is worse: loop invariant motion : 23.13 (17%) usr 0.04 (6%) sys 23.94 (15%) wall tree iv optimization : 68.67 (49%) usr 0.29 (40%) sys 74.50 (50%) wall For maincr.f, we have: tree iv optimization : 9.72 (23%) usr 0.06 (13%) sys 10.10 (23%) wall
I cannot reproduce the ivopts problem on daten.f (ivopts are <2% for me, which is not great, but also not so terrible). IM problem reproduces. mainrc.f currently runs out of memory for me.
Actually mainrc.f does not run out of memory, but causes segfault during garbage collection (infinite recursion).
the ivopts stuff may have been fixed by your ivopts patch for important candidates. i'll try maincr again.
IM problem seems to be caused by some inefficiency in store motion (I suspect scanning loop repeatedly for various insignificant virtual operands). Anyway, the patch for PR 17133 (complete rewrite of store motion) fixes this (reduces the compile time to <1%). http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01120.html
I see LICM on some other code high up on the radar.
Hmm, I found another testcase where we are slow at LIM: loop invariant motion : 2.55 ( 5%) usr 0.40 ( 3%) sys 3.36 ( 4%) wall This is PR8361. Zdenek can you update your patch for the changes where V_MUST_DEF changes and see what the compile time improvements you get with the patch?
Subject: Re: [4.0 Regression] Significant compile time increases for sixtrack with tree LICM and IV optimization > ------- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-06 00:02 ------- > Hmm, I found another testcase where we are slow at LIM: > loop invariant motion : 2.55 ( 5%) usr 0.40 ( 3%) sys 3.36 ( 4%) wall > This is PR8361. > > Zdenek can you update your patch for the changes where V_MUST_DEF changes and see what the > compile time improvements you get with the patch? there is an updated version of the patch http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01642.html that should work (possibly with minor changes due to some renaming).
Any news here? This is one of the more serious compile time problems in GCC4, I've seen a number of cases where these passes are high up in the profile.
Subject: Re: [4.0 Regression] Significant compile time increases for sixtrack with tree LICM and IV optimization > Any news here? This is one of the more serious compile time problems > in GCC4, I've seen a number of cases where these passes are high up in > the profile. As for ivopts, the problems reported under this PR are solved. So if you have a testcase where ivopts eat more than 1% of time without a good reason, please let me know. I will try to update and resend the patch for inefficiency in store motion.
18687 is one example where IVopts takes a significant amount of time (9%).
Updated version of the patch: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00205.html
Is this patch still 4.0 material? No reviewers have looked at it yet :-/
Does anyone have new numbers?
Current mainline with -O3 -funroll-loops daten.f takes 3.6s to compile. loop invariant motion : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree canonical iv : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 8 kB ( 0%) ggc Multiple compilations finally produce an evenly distributed profile: samples % image name symbol name 91 4.8097 no-vmlinux (no symbols) 32 1.6913 f951 cse_insn 29 1.5328 f951 count_reg_usage 28 1.4799 f951 mark_set_1 26 1.3742 f951 constrain_operands 23 1.2156 f951 bitmap_bit_p 22 1.1628 f951 find_reg_note 22 1.1628 f951 init_alias_analysis 20 1.0571 f951 for_each_rtx_1 19 1.0042 f951 invalidate
I think we can call this one fixed for now, i'll reopen if it goes crazy again