From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59405 invoked by alias); 16 Apr 2019 11:25:54 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 59391 invoked by uid 89); 16 Apr 2019 11:25:53 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=50000, UD:call.c, H*i:sk:5dS7eD_, call.c X-HELO: mail-lf1-f65.google.com Received: from mail-lf1-f65.google.com (HELO mail-lf1-f65.google.com) (209.85.167.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 16 Apr 2019 11:25:52 +0000 Received: by mail-lf1-f65.google.com with SMTP id u17so15740395lfi.3 for ; Tue, 16 Apr 2019 04:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0Lf5dF6DdUSPYCAE+Q+myLJYiryGaV2G53dg9v4908Q=; b=BElNg7jYQ1uSvZ0NWOxYlB/ajgfDUxDZ6oUQH+4JEq7f4A/Q9ISs8VlTGmKiz8oia/ +wI5HUObdhigD1fT/ggSltyz6NEp1LE+Ur6TcXfV72wmhS+tO1lyV343Gl0DsVz92Fso BaVuUaW4I0vSvwsdXL8YncHchxu67VSJXe/sMsFJuFJDOL9FA5gMwjjm3rxAWH17HSN2 5VQGIcWj3L4uO9NNA6Ngr4esFnRMMcGWIbvGEVhvCfX4Zj+DzYLEB992ZUH60Gdb7fa5 0xwcFbxpjE7+miw8ZczhsObmUDj+/Pve0Pd425AslKX8Pr/jjcpFx9xgudSWo40D6nm0 Zq3g== MIME-Version: 1.0 References: <6f547f38-1751-c003-b5ae-52dae776d39a@suse.cz> <65289853-0db4-4645-74b4-869443addf1a@suse.cz> <20190415133326.GT21066@tucnak> In-Reply-To: From: Richard Biener Date: Tue, 16 Apr 2019 11:25:00 -0000 Message-ID: Subject: Re: GCC 8 vs. GCC 9 speed and size comparison To: Michael Matz Cc: =?UTF-8?Q?Martin_Li=C5=A1ka?= , Jakub Jelinek , GCC Development , Jan Hubicka , Martin Jambor Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00165.txt.bz2 On Tue, Apr 16, 2019 at 11:56 AM Richard Biener wrote: > > On Tue, Apr 16, 2019 at 10:53 AM Michael Matz wrote: > > > > Hello Martin, > > > > On Tue, 16 Apr 2019, Martin Li=C5=A1ka 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- 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) =3D=3D INTEGER_TYPE - && !char_type_p (type) - && TREE_CODE (t) =3D=3D INTEGER_CST + if (TREE_CODE (t) =3D=3D INTEGER_CST + && !TREE_OVERFLOW (t) + && TREE_CODE (type) =3D=3D 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 =3D 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 possib= le 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 li= st > > > 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= =3D20 for all > > > benchmarks, I see green numbres for GCC 9! > > > > > > Martin > > > > > > > > > > > > > > > Ciao, > > > > Michael. > > > > > > > > > >