From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 4A44B385E83F for ; Wed, 16 Mar 2022 08:20:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4A44B385E83F Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id B6B702112B; Wed, 16 Mar 2022 08:20:14 +0000 (UTC) Received: from murzim.suse.de (murzim.suse.de [10.160.4.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 8FD06A3B87; Wed, 16 Mar 2022 08:20:14 +0000 (UTC) Date: Wed, 16 Mar 2022 09:20:14 +0100 (CET) From: Richard Biener To: Roger Sayle cc: 'GCC Patches' , 'Marc Glisse' Subject: Re: [PATCH v2] Performance/size improvement to single_use when matching GIMPLE. In-Reply-To: <001a01d8390d$97d052c0$c770f840$@nextmovesoftware.com> Message-ID: <33o8n56p-pp1p-r77p-2s77-p1spn65345q4@fhfr.qr> References: <001a01d8390d$97d052c0$c770f840$@nextmovesoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2022 08:20:18 -0000 On Wed, 16 Mar 2022, Roger Sayle wrote: > > Here's version 2 of my patch, incorporating Richard Biener's suggestions. > I've also done an analysis of the stage3 sizes of gimple-match.o on > x86_64-pc-linux-gnu, which I believe is dominated by debug information, > the .o file is 30MB in stage3, but only 4.8M in stage2. Before my > proposed patch gimple-match.o is 31385160 bytes. The patch as proposed > yesterday (using a single loop in single_use) reduces that to 31105040 > bytes, saving 280120 bytes. The suggestion to remove the "inline" > keyword saves only 56 more bytes, but annotating ATTRIBUTE_PURE on a > function prototype was curiously effective, saving 1888 bytes. > > before: 31385160 > after: 31105040 saved 280120 > -inline: 31104984 saved 56 > +pure: 31103096 saved 1888 > > I'll post two more patches later today, that save an additional 53K > and 58K respectively (by tweaking genmatch) but the issue is with the > size of debugging info (or something else?). You can always use the 'size' tool and report the size of the text section only ... especially interesting for folks are also compile-times of stage2 gimple-match.cc since that's built by the -O0 compiled checking-enabled stage1 compiler during bootstrap. > This revised patch has been tested on x86_64-pc-linux-gnu with > make bootstrap and make -k check with no new failures. > Ok for mainline? OK. Thanks, Richard. > > 2022-03-16 Roger Sayle > Richard Biener > > gcc/ChangeLog > * gimple-match-head.cc (single_use): Implement inline using a > single loop. > > > Thanks in advance, > Roger > -- > > > -----Original Message----- > > From: Richard Biener > > Sent: 15 March 2022 09:18 > > To: Roger Sayle > > Cc: 'GCC Patches' ; 'Marc Glisse' > > > > Subject: Re: [PATCH] Performance/size improvement to single_use when > > matching GIMPLE. > > > > On Tue, 15 Mar 2022, Roger Sayle wrote: > > > > > > > > > > > This patch improves the implementation of single_use as used in code > > > > > > generated from match.pd for patterns using :s. The current > > > implementation > > > > > > contains the logic "has_zero_uses (t) || has_single_use (t)" which > > > > > > performs a loop over the uses to first check if there are zero > > > non-debug > > > > > > uses [which is rare], then another loop over these uses to check if > > > there > > > > > > is exactly one non-debug use. This can be better implemented using a > > > > > > single loop. > > > > > > > > > > > > This function is currently inlined over 800 times in gimple-match.cc, > > > > > > whose .o on x86_64-pc-linux-gnu is now up to 30 Mbytes, so speeding up > > > > > > and shrinking this function should help offset the growth in match.pd > > > > > > for GCC 12. > > > > > > > > > > > > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap > > > > > > and make -k check with no new failures. Ok for mainline? > > > > Note the intent of has_zero_uses () is even simpler - it's the case for > when > > there's no SSA operand info on the stmt (no update_stmt called yet). More > > precisely it wants to catch the case where the definition of the SSA name > is not > > in the IL. > > > > I'm not sure if we want to twist the effective semantics at this point (I > guess we > > do not want that), so the patch looks like an improvement. But may I ask > to > > move the function out of line for even more savings? Just put it in > gimple- > > match-head.cc and have it not declared inline. I think we may want to go > as far > > and declare the function 'pure' using ATTRIBUTE_PURE. > > > > > > > > > > > > > > > > > 2022-03-15 Roger Sayle > > > > > > > > > > > > gcc/ChangeLog > > > > > > * gimple-match-head.cc (single_use): Implement inline using a > > > > > > single loop. > > > > > > > > > > > > Thanks in advance, > > > > > > Roger > > > > > > -- > > > > > > > > > > > > > > > > -- > > Richard Biener > > SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, > > Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg) > -- Richard Biener SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)