This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix PR41573, remove pass_remove_useless_stmts


On 10/07/2009 07:24 AM, Richard Guenther wrote:
On Wed, Oct 7, 2009 at 2:29 PM, Michael Matz<matz@suse.de> wrote:
Hi,

remove_useless_stmts folds statements at a time where not the whole
optimization engine is initialized yet, which causes the segfault of the
above bugreport.  Now, instead of just fixing the symptom I thought maybe
we can get rid of the whole pass instead.  Digging around it seems to have
been rotting away for some years already, while occasionally making it
remove less stmts or fixing other bugs, somewhen being split into
cfg_remove_useless_stmts, which shortly after was removed again.  It
survived tuplification living its meagre life on and on.

To determine its meagreness I added some statistics code to see what it
actually still removes and measured a whole bootstrap cycle with testsuite
(all languages+Ada), and this is the result:

number of compiler invocations: 70332
overall number of repeats:     214136
  (When something is changed by r_u_s it repeats the scan of all insns
  again)
overall insns visited:   1025945788
  of those changed at all:   1111266 (a whopping promille)
nr of conditional insns:    4136111
  of those trivial true:       84084
         trivial false:      152987
        same destination:         8 (wow)
nr unconditional gotos:   244390760
  of those fallthru:          478812
nr of GIMPLE_BIND:          2268987
  of those removed:           304083
nr of TRY_FINALLY:           201032
  of those empty eval:         17130
          empty cleanup:       2090
         nonbranching body:    7095
nr of TRY_CATCH:             178155
  of those empty cleanup:          0
    or non-throwing body:     61094
nr of stale GIMPLE_NOP:        3883
nr of other insns:        774766860

So, it removes a few gotos, but that will also be done shortly after this
pass in optimization (and could be done in the gimplifier already).  It
removes some GIMPLE_BIND, where all of them will go away two passes later
anyway.  It does some cleanup on the exception constructs, but with rths
rewrite to expand them on trees something equivalent will be done three
passes later.

So, I removed the whole thing.  tramp3d compiles even a bit faster on -O0
now.  Bootstrap times are unaffected.

Doing this without regressions requires some minor surgery, mostly due to
the pass formerly calling fold on all statements:
* the builtin folders should use, well fold, not buildX directly, where
  applicable
* exception lowering should accept empty cleanups and do the obvious thing
* exception region copying (used by omp lowering) should deal gracefully
  with empty labels (left over when expanding trivial regions sometimes,
  until cleanup_eh)
* free_lang_data shouldn't null out DECL_INITIAL for static constants
  (and the LTO streamer then needs to accept this)
* LTO streamer should deal with GIMPLE_NOP (they're left until expand
  with -O0)

Regstrapped on x86_64-linux, no regressions, all languages+Ada. Okay for
trunk?
Ok with ...

--- testsuite/gcc.dg/tree-ssa/foldstring-1.c    (revision 152447)
+++ testsuite/gcc.dg/tree-ssa/foldstring-1.c    (working copy)
@@ -1,5 +1,5 @@
  /* { dg-do compile } */
-/* { dg-options "-O1 -fdump-tree-useless" } */
+/* { dg-options "-O1 -fdump-tree-fre" } */

void
arf ()
@@ -7,5 +7,5 @@ arf ()
if (""[0] == 0)
blah ();
}
-/* { dg-final { scan-tree-dump-times "= 0;" 1 "useless"} } */
-/* { dg-final { cleanup-tree-dump "useless" } } */
+/* { dg-final { scan-tree-dump-times "= 0;" 1 "fre"} } */
+/* { dg-final { cleanup-tree-dump "fre" } } */
Changing that to scan the gimple dump, XFAILing it and file
a missed-optimization PR for fold / gimplification.

Oh, and please wait some 24h in case somebody has strong
reasons to keep that pass.
I don't think there's any reason to wait -- r_u_s is mostly a holdover from a point prior to flattening the IR. The kinds of things it finds (or better stated, found) aren't terribly important, it was always of marginal value given the compile time cost.

jeff



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]