This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 8 vs. GCC 9 speed and size comparison
On Tue, Apr 16, 2019 at 11:56 AM Richard Biener
<richard.guenther@gmail.com> wrote:
>
> On Tue, Apr 16, 2019 at 10:53 AM Michael Matz <matz@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.
> > > >
> > >
> > >