Re: GCC 8 vs. GCC 9 speed and size comparison

[Richard Biener]

On Tue, Apr 16, 2019 at 11:56 AM Richard Biener
<richard.guent...@gmail.com> wrote:
>
> On Tue, Apr 16, 2019 at 10:53 AM Michael Matz <m...@suse.de> wrote:
> >
> > Hello Martin,
> >
> > On Tue, 16 Apr 2019, Martin Liška wrote:
> >
> > > Yes, except kdecore.cc I used in all cases .ii pre-processed files. I'm
> > > going to start using kdecore.ii as well.
> >
> > If the kdecore.cc is the one from me it's also preprocessed and doesn't
> > contain any #include directives, I just edited it somewhat to be
> > compilable for different architecture.
>
> Btw, the tramp3d sources on our testers _do_ contain #include directives.

So for the parser it's small differences that accumulate, for example
a lot more comptype calls via null_ptr_cst_p (via char_type_p) via the new
conversion_null_warnings which is called even without any warning option.

Possible speedup to null_ptr_cst_p is to avoid the expensive char_type_p
(called 50000 times in GCC 9 vs. only 2000 times in GCC 8):

Index: gcc/cp/call.c
===================================================================
--- gcc/cp/call.c       (revision 270387)
+++ gcc/cp/call.c       (working copy)
@@ -541,11 +541,11 @@ null_ptr_cst_p (tree t)
       STRIP_ANY_LOCATION_WRAPPER (t);

       /* Core issue 903 says only literal 0 is a null pointer constant.  */
-      if (TREE_CODE (type) == INTEGER_TYPE
-         && !char_type_p (type)
-         && TREE_CODE (t) == INTEGER_CST
+      if (TREE_CODE (t) == INTEGER_CST
+         && !TREE_OVERFLOW (t)
+         && TREE_CODE (type) == INTEGER_TYPE
          && integer_zerop (t)
-         && !TREE_OVERFLOW (t))
+         && !char_type_p (type))
        return true;
     }
   else if (CP_INTEGRAL_TYPE_P (type))

brings down the number of char_type_p calls to ~5000.  Still null_ptr_cst_p
calls are 150000 vs. 17000, caused by the conversion_null_warnings code
doing

  /* Handle zero as null pointer warnings for cases other
     than EQ_EXPR and NE_EXPR */
  else if (null_ptr_cst_p (expr) &&
           (TYPE_PTR_OR_PTRMEM_P (totype) || NULLPTR_TYPE_P (totype)))
    {

similarly "easy" to short-cut most of them:

@@ -6882,8 +6882,8 @@ conversion_null_warnings (tree totype, t
     }
   /* Handle zero as null pointer warnings for cases other
      than EQ_EXPR and NE_EXPR */
-  else if (null_ptr_cst_p (expr) &&
-          (TYPE_PTR_OR_PTRMEM_P (totype) || NULLPTR_TYPE_P (totype)))
+  else if ((TYPE_PTR_OR_PTRMEM_P (totype) || NULLPTR_TYPE_P (totype))
+          && null_ptr_cst_p (expr))
     {
       location_t loc =
get_location_for_expr_unwinding_for_system_header (expr);
       maybe_warn_zero_as_null_pointer_constant (expr, loc);

brings them down to 25000.

All this looks like there's plenty of low-hanging micro-optimization possible in
the C++ frontend.

I'm going to test the above two hunks, the overall savings are of course
small (and possibly applicable to branches as well).

Richard.


> Richard.
>
> >
> > Ciao,
> > Michael.
> >
> > >
> > > As Honza pointed out in the email that hasn't reached this mailing list
> > > due to file size, there's a significant change in inline-unit-growth. The 
> > > param
> > > has changed from 20 to 40 for GCC 9. Using --param inline-unit-growth=20 
> > > for all
> > > benchmarks, I see green numbres for GCC 9!
> > >
> > > Martin
> > >
> > > >
> > > >
> > > > Ciao,
> > > > Michael.
> > > >
> > >
> > >