From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68386 invoked by alias); 7 Apr 2015 23:28:49 -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 68368 invoked by uid 89); 7 Apr 2015 23:28:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f175.google.com Received: from mail-ob0-f175.google.com (HELO mail-ob0-f175.google.com) (209.85.214.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 07 Apr 2015 23:28:47 +0000 Received: by obbeb7 with SMTP id eb7so40432968obb.3 for ; Tue, 07 Apr 2015 16:28:45 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.116.130 with SMTP id jw2mr28464247obb.48.1428449325651; Tue, 07 Apr 2015 16:28:45 -0700 (PDT) Received: by 10.202.229.72 with HTTP; Tue, 7 Apr 2015 16:28:45 -0700 (PDT) In-Reply-To: <20150407203319.GA91010@kam.mff.cuni.cz> References: <20150306141531.GA27860@msticlxl57.ims.intel.com> <20150402205551.GJ21276@atrey.karlin.mff.cuni.cz> <20150403170510.GO21276@atrey.karlin.mff.cuni.cz> <20150407141133.GC11622@msticlxl57.ims.intel.com> <20150407203319.GA91010@kam.mff.cuni.cz> Date: Tue, 07 Apr 2015 23:28:00 -0000 Message-ID: Subject: Re: [CHKP] Support returned bounds in thunks expand From: Ilya Enkovich To: Jan Hubicka Cc: gcc-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00286.txt.bz2 2015-04-07 23:33 GMT+03:00 Jan Hubicka : >> > > >> > > The problem with instrumented call is that instrumented function >> > > returns two values and call lhs gets only the first one. Thus we >> > > generate bndret call to get the second one to build own return with >> > > two values. >> > >> > I see, patch is OK then (preferably merging as much as possible with ipa-split) >> > >> > Honza >> >> Here is a refactored version with common code moved to tree-chkp.c. Bootstrapped and tested on x86_64-unknown-linux-gnu. Does it look OK? >> >> Thanks, >> Ilya >> -- >> gcc/ >> >> 2015-04-07 Ilya Enkovich >> >> * tree-chkp.h (chkp_insert_retbnd_call): New. >> * tree-chkp.c (chkp_insert_retbnd_call): New. >> * ipa-split.c (insert_bndret_call_after): Remove. >> (split_function): Use chkp_insert_retbnd_call. >> * cgraphunit.c (cgraph_node::expand_thunk): Build returned >> bounds for instrumented functions. >> >> gcc/testsuite/ >> >> 2015-04-07 Ilya Enkovich >> >> * gcc/testsuite/gcc.target/i386/thunk-retbnd.c: New. > > OK, thanks! >> @@ -1697,6 +1698,17 @@ cgraph_node::expand_thunk (bool output_asm_thunks, bool force_gimple_thunk) >> gsi_insert_after (&bsi, call, GSI_NEW_STMT); >> if (!alias_is_noreturn) >> { >> + if (instrumentation_clone >> + && !DECL_BY_REFERENCE (resdecl) >> + && restmp >> + && BOUNDED_P (restmp)) >> + { >> + resbnd = chkp_insert_retbnd_call (NULL, restmp, &bsi); >> + create_edge (get_create (gimple_call_fndecl (gsi_stmt (bsi))), >> + as_a (gsi_stmt (bsi)), >> + callees->count, callees->frequency); >> + } > > Is there any reasons the rtbnd builtin call is not gimple_call_internal_p? > That way we would not need to worry about representing this in callgraph. Function called to get returned bounds (similar to many other instrumentation functions) is target dependent. Internal function usage would require significant redesign. Thanks, Ilya > > Honza