| Message ID | 001a01d8390d$97d052c0$c770f840$@nextmovesoftware.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v2] Performance/size improvement to single_use when matching GIMPLE. | expand |
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 <roger@nextmovesoftware.com> > Richard Biener <rguenther@suse.de> > > gcc/ChangeLog > * gimple-match-head.cc (single_use): Implement inline using a > single loop. > > > Thanks in advance, > Roger > -- > > > -----Original Message----- > > From: Richard Biener <rguenther@suse.de> > > Sent: 15 March 2022 09:18 > > To: Roger Sayle <roger@nextmovesoftware.com> > > Cc: 'GCC Patches' <gcc-patches@gcc.gnu.org>; 'Marc Glisse' > > <marc.glisse@inria.fr> > > 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 <roger@nextmovesoftware.com> > > > > > > > > > > > > gcc/ChangeLog > > > > > > * gimple-match-head.cc (single_use): Implement inline using a > > > > > > single loop. > > > > > > > > > > > > Thanks in advance, > > > > > > Roger > > > > > > -- > > > > > > > > > > > > > > > > -- > > Richard Biener <rguenther@suse.de> > > SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, > > Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg) >
diff --git a/gcc/gimple-match-head.cc b/gcc/gimple-match-head.cc index 74d5818..1c74d38 100644 --- a/gcc/gimple-match-head.cc +++ b/gcc/gimple-match-head.cc @@ -1160,10 +1160,28 @@ types_match (tree t1, tree t2) non-SSA_NAME (ie constants) and zero uses to cope with uses that aren't linked up yet. */ -static inline bool -single_use (tree t) +static bool +single_use (const_tree) ATTRIBUTE_PURE; + +static bool +single_use (const_tree t) { - return TREE_CODE (t) != SSA_NAME || has_zero_uses (t) || has_single_use (t); + if (TREE_CODE (t) != SSA_NAME) + return true; + + /* Inline return has_zero_uses (t) || has_single_use (t); */ + const ssa_use_operand_t *const head = &(SSA_NAME_IMM_USE_NODE (t)); + const ssa_use_operand_t *ptr; + bool single = false; + + for (ptr = head->next; ptr != head; ptr = ptr->next) + if (USE_STMT(ptr) && !is_gimple_debug (USE_STMT (ptr))) + { + if (single) + return false; + single = true; + } + return true; } /* Return true if math operations should be canonicalized,