From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20718 invoked by alias); 26 May 2014 01:01:16 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 20707 invoked by uid 89); 26 May 2014 01:01:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 26 May 2014 01:01:14 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 1132A54172F; Mon, 26 May 2014 03:01:10 +0200 (CEST) Date: Mon, 26 May 2014 01:01:00 -0000 From: Jan Hubicka To: Richard Biener Cc: GCC Patches , Jan Hubicka Subject: Re: [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags Message-ID: <20140526010110.GB15226@kam.mff.cuni.cz> References: <20140521131634.178838544@virgil.suse.cz> <20140521131634.646352575@virgil.suse.cz> <20140522124952.GA13095@virgil.suse> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-05/txt/msg02130.txt.bz2 > On Thu, May 22, 2014 at 2:49 PM, Martin Jambor wrote: > > Hi, > > > > On Wed, May 21, 2014 at 04:27:32PM +0200, Richard Biener wrote: > >> On Wed, May 21, 2014 at 3:16 PM, Martin Jambor wrote: > >> > Hi, > >> > > >> > this demonstrates how results of ipa-prop escape analysis from > >> > previous patches can be used at a later stage of compilation by > >> > directly returning them from gimple_call_arg_flags which currently > >> > relies on fnspec annotations. > >> > > >> > Bootstrapped and tested on x86_64-linux and also passes LTO bootstrap. > >> > I have only had a brief look at behavior of this in SPEC 2006 and for > >> > example in astar 1.19% of invocations of gimple_call_arg_flags return > >> > noescape where we previously never did and in calculix this increases > >> > from 15.62% (from annotations) to 18.14%. Noclobber flag is reported > >> > far less often still but for example in gamess that number raises from > >> > 5.21% to 7.66%. > >> > > >> > Thanks, > >> > > >> > Martin > >> > > >> > > >> > 2014-04-30 Martin Jambor > >> > > >> > * gimple.c: Include cgraph.h. > >> > (gimple_call_arg_flags): Also query bitmaps in cgraph_node. > >> > > >> > Index: src/gcc/gimple.c > >> > =================================================================== > >> > --- src.orig/gcc/gimple.c > >> > +++ src/gcc/gimple.c > >> > @@ -47,7 +47,7 @@ along with GCC; see the file COPYING3. > >> > #include "demangle.h" > >> > #include "langhooks.h" > >> > #include "bitmap.h" > >> > - > >> > +#include "cgraph.h" > >> > > >> > /* All the tuples have their operand vector (if present) at the very bottom > >> > of the structure. Therefore, the offset required to find the > >> > @@ -1349,32 +1349,50 @@ int > >> > gimple_call_arg_flags (const_gimple stmt, unsigned arg) > >> > { > >> > tree attr = gimple_call_fnspec (stmt); > >> > + int ret; > >> > > >> > - if (!attr || 1 + arg >= (unsigned) TREE_STRING_LENGTH (attr)) > >> > - return 0; > >> > - > >> > - switch (TREE_STRING_POINTER (attr)[1 + arg]) > >> > + if (attr && 1 + arg < (unsigned) TREE_STRING_LENGTH (attr)) > >> > { > >> > - case 'x': > >> > - case 'X': > >> > - return EAF_UNUSED; > >> > - > >> > - case 'R': > >> > - return EAF_DIRECT | EAF_NOCLOBBER | EAF_NOESCAPE; > >> > - > >> > - case 'r': > >> > - return EAF_NOCLOBBER | EAF_NOESCAPE; > >> > - > >> > - case 'W': > >> > - return EAF_DIRECT | EAF_NOESCAPE; > >> > - > >> > - case 'w': > >> > - return EAF_NOESCAPE; > >> > + switch (TREE_STRING_POINTER (attr)[1 + arg]) > >> > + { > >> > + case 'x': > >> > + case 'X': > >> > + ret = EAF_UNUSED; > >> > + break; > >> > + case 'R': > >> > + ret = EAF_DIRECT | EAF_NOCLOBBER | EAF_NOESCAPE; > >> > + break; > >> > + case 'r': > >> > + ret = EAF_NOCLOBBER | EAF_NOESCAPE; > >> > + break; > >> > + case 'W': > >> > + ret = EAF_DIRECT | EAF_NOESCAPE; > >> > + break; > >> > + case 'w': > >> > + ret = EAF_NOESCAPE; > >> > + break; > >> > + case '.': > >> > + default: > >> > + ret = 0; > >> > + } > >> > + } > >> > + else > >> > + ret = 0; > >> > > >> > - case '.': > >> > - default: > >> > - return 0; > >> > + tree callee_decl = gimple_call_fndecl (stmt); > >> > + if (callee_decl) > >> > + { > >> > + cgraph_node *callee_node = cgraph_get_node (callee_decl); > >> > + if (callee_node) > >> > + { > >> > + if (cgraph_param_noescape_p (callee_node, arg)) > >> > + ret |= EAF_NOESCAPE; > >> > + if (cgraph_param_noclobber_p (callee_node, arg)) > >> > + ret |= EAF_NOCLOBBER; > >> > >> That's quite expensive. I guess we need a better way to store > >> those? > > > > if we want to avoid the cgraph_node lookup, then I think we need to > > store this information in the decl or struct function. That is > > certainly possible and might even be more appropriate. > > Can we? If the body is not readily available we only have decl and > cgraph-node, not struct function. Yep, indeed I think cgraph_node is good place to home this so it can work with partitioning. With the weekend changes to have direct pointer, I guess the performance problems are gone. My plan is to add a template that makes it easy to annotate symbol nodes either by array (as we do by hand now in ipa-inline/ipa-prop and other places) or by hashtable (for sparse data, like thunk information, or comdat information) and move some of stuff we currently have in cgraph there (rtl info, thunks, aliases, comdats, nested function tree can all go). For performance critical stuff I have no problem adding it into cgraph nodes themselves. If someone wants to beat me and write GGC friendly template for this, I would very welcome it. > > I suppose we could exchange the struct function pointer in > tree_function_decl for a cgraph_node pointer and put > the struct function pointer into the cgraph_node. > > Of course that may have impacts on FEs who might create > struct function before creating a cgraph node. But at least > it would avoid enlarging FUNCTION_DECL. > > In the end most of the tree_decl_with_vis stuff should move over to symtab > and var-decls should get a varpool_node pointer as well. > > Back to the call flags stuff - I also meant the representation of the > "fn spec" attribute. Rather than parsing that again and again move > it to a better place (which you seem to invent?) and better unified > representation. > > Can you try if removing the cgraph hash is possible with the > struct function pointer idea? If there are no problems, I plan to move also DECL_SECTION and do some cleanups to my weekend change (in particular I do not like the way it works with duplicate_decl. Perhaps we don't really need to duplicate this info). We can experiment with assembler name and struct function next. Honza > > Thanks, > Richard. > > > Thanks, > > > > Martin > > > >> > >> > + } > >> > } > >> > + > >> > + return ret; > >> > } > >> > > >> > /* Detects return flags for the call STMT. */ > >> >