From patchwork Thu Dec 20 14:15:34 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Biener X-Patchwork-Id: 207667 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 7B28F2C0094 for ; Fri, 21 Dec 2012 01:17:04 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1356617825; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Date: From:To:Cc:Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=pTAgFC4CFYm0/P+bPZoiHyMgs8s=; b=beSrzoA1rreuZHq pQ4MBv8XATttIDudbBLNr5KwAfgrpqMDHMSca+XppbHAQ652GuwoKtrmDuuFwhJC mrhuxtqVK5NsYlEzBAo4grhfHB9EjrLE8n4UDGxrzbT/lEZXC6cEWcKtmrsCsRcR CKxTrB7byXFEreSaZN2Emi5SsyDA= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Date:From:To:Cc:Subject:In-Reply-To:Message-ID:References:User-Agent:MIME-Version:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=rZPk40OJgYFYs6wpvIxzOV3ab7ZNvWkunYRouFvzEpFLiFMhtaC3PWepYfWeOX 9K2qGpCmG2kigemodum3aNtDYWtIYxqKwsMSqGXY8y1aCu5qYT51xrATqJHB1mXZ Xm8cF/7kT7tK5+Hx0Gze2nc2RJAH0LGb18Bnd0s0ObkTY=; Received: (qmail 32377 invoked by alias); 20 Dec 2012 14:16:56 -0000 Received: (qmail 32361 invoked by uid 22791); 20 Dec 2012 14:16:54 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_THREADED, RCVD_IN_DNSWL_HI, TW_TM, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 20 Dec 2012 14:16:45 +0000 Received: from relay1.suse.de (unknown [195.135.220.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 03E41A4C0E; Thu, 20 Dec 2012 15:16:43 +0100 (CET) Date: Thu, 20 Dec 2012 15:15:34 +0100 (CET) From: Richard Biener To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Further restrict TER replacing over calls (PR55752) In-Reply-To: Message-ID: References: <20121220135900.GB2315@tucnak.redhat.com> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On Thu, 20 Dec 2012, Richard Biener wrote: > On Thu, 20 Dec 2012, Jakub Jelinek wrote: > > > On Thu, Dec 20, 2012 at 02:51:55PM +0100, Richard Biener wrote: > > > In the PR we perform expression replacement of an FP operation > > > across a builtin call that sets the FP control register. This > > > patch restricts replacement across calls further, from allowing > > > all builtins to only allowing those without side-effects. > > > > > > Allowing replacement over calls at all was to not pessimize > > > FP code generation for example for sqrt which is most often > > > expanded to a single instruction. > > > > > > Bootstrap and regtest running on x86_64-unknown-linux-gnu. > > > > > > Comments? > > > > Wouldn't it be better to have there a list of known builtins over which it > > is fine to do TER? I'd bet most of memory or string builtins that don't > > call malloc/free should be still ok, but they surely have side-effects. > > I'm not sure - the original reason was that replacing across calls > made us spill more because there was a call. We agreed that replacing > across calls isn't usually a good idea but put in the (admittedly bad) > workaround to still allow doing so across likely-not-calls. > string builtins generally will expand to calls though. > > I was thinking of even making it stronger and increment "cur_call_cnt" > when the stmt (even non-call) has side-effects (would for example > cover volatile asms or general volatile touching insns). Like so: /* Now see if we are creating a new expression or not. */ Richard. Index: gcc/tree-ssa-ter.c =================================================================== --- gcc/tree-ssa-ter.c (revision 194632) +++ gcc/tree-ssa-ter.c (working copy) @@ -681,12 +681,13 @@ find_replaceable_in_bb (temp_expr_table_ kill_expr (tab, partition); } - /* Increment counter if this is a non BUILT_IN call. We allow - replacement over BUILT_IN calls since many will expand to inline - insns instead of a true call. */ - if (is_gimple_call (stmt) - && !((fndecl = gimple_call_fndecl (stmt)) - && DECL_BUILT_IN (fndecl))) + /* Increment counter if this is not a BUILT_IN call or a stmt with + side-effects. We allow replacement over BUILT_IN calls + since many will expand to inline insns instead of a true call. */ + if (gimple_has_side_effects (stmt) + || (is_gimple_call (stmt) + && !((fndecl = gimple_call_fndecl (stmt)) + && DECL_BUILT_IN (fndecl)))) cur_call_cnt++;