From patchwork Fri Sep 21 21:00:26 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aldy Hernandez X-Patchwork-Id: 185931 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 6B19C2C0081 for ; Sat, 22 Sep 2012 07:00:53 +1000 (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=1348866053; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=x4iHGTL NQ5M2WB9TJNe3p3DvZ7I=; b=PFpiRYPT/Kvbt3uNtQk9bXLULNU6n4gsBpMXLuG GdosZRJJKbUjhl7rLuan0DloQd9e9pSvMYJ2lAmn4todhZ317xvb4T7BsQszTVBG NqTwPK/8PdZnLexEw1ZAv8MiHpGKPXV6Av7mA67cPkkij4i2vz2VPwfX+zTfK+Fa oPlo= 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:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=gYvDzdJ9vOps4WiL9hP6s4kSep1pjGHDR51mjz7rhlxZCzfEDNMiGLvwqa3BKS X9F02Ms0HKEP8Kedw6nJDpsDyY/+5ngWd0vBUxT2p5VpLfZXeb7hGBLp4CcXX0oL nhIMdW4dbxc4ybGlpy/pW7qJhXeFzTTJK0Um2C6KnB7Pc=; Received: (qmail 1653 invoked by alias); 21 Sep 2012 21:00:44 -0000 Received: (qmail 1633 invoked by uid 22791); 21 Sep 2012 21:00:41 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, RP_MATCHES_RCVD, SPF_HELO_PASS, TW_TM X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 21 Sep 2012 21:00:28 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q8LL0R0k013578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 21 Sep 2012 17:00:27 -0400 Received: from houston.quesejoda.com (vpn-10-64.rdu.redhat.com [10.11.10.64]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q8LL0Q54022870; Fri, 21 Sep 2012 17:00:26 -0400 Message-ID: <505CD56A.3040608@redhat.com> Date: Fri, 21 Sep 2012 16:00:26 -0500 From: Aldy Hernandez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: Richard Henderson , gcc-patches Subject: [patch] PR middle-end/53850: memset builtin problem in TM 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 The problem here is that a simple loop gets transformed into a __builtin_memset by the loop distribution pass: + __transaction_atomic + { + for (i = 0; i < 100; ++i) + pp[i] = 0x33; + } Since this pass occurs after IPA-tm, the new call to __builtin_memset hasn't been analyzed so it has no cgraph node associated with it. Barring major surgery to the entire TM infrastructure, I think the easiest thing to do is find the memset replacement late in expand_call_tm and create a cgraph node there. I also experimented with generating the __builtin_TM_memset in the loop distribution pass, but that seemed overly kludgy, as every pass adding calls after IPA passes would have to have intimate knowledge of the TM builtins. The patch below seemed like a better idea. Tested on x86-64 Linux. OK? p.s. What do you think of the tm_may_enter_irr comment below? PR middle-end/53850 * trans-mem.c (expand_call_tm): Handle late built built-ins. diff --git a/gcc/testsuite/gcc.dg/tm/pr53850.c b/gcc/testsuite/gcc.dg/tm/pr53850.c new file mode 100644 index 0000000..ca2c604 --- /dev/null +++ b/gcc/testsuite/gcc.dg/tm/pr53850.c @@ -0,0 +1,15 @@ +/* { dg-do compile } */ +/* { dg-options "-fgnu-tm -O3" } */ + +unsigned char pp[100]; + +void +foo (void) +{ + int i; + __transaction_atomic + { + for (i = 0; i < 100; ++i) + pp[i] = 0x33; + } +} diff --git a/gcc/trans-mem.c b/gcc/trans-mem.c index 242b470..4965b3d 100644 --- a/gcc/trans-mem.c +++ b/gcc/trans-mem.c @@ -2296,8 +2296,27 @@ expand_call_tm (struct tm_region *region, } node = cgraph_get_node (fn_decl); - /* All calls should have cgraph here. */ - gcc_assert (node); + /* All calls should have cgraph here. */ + if (!node) + { + /* We can have a nodeless call here if some pass after IPA-tm + added uninstrumented calls. For example, loop distribution + can transform certain loop constructs into __builtin_mem* + calls. In this case, see if we have a suitable TM + replacement and fill in the gaps. */ + tree repl = find_tm_replacement_function (fn_decl); + if (repl) + { + gimple_call_set_fndecl (stmt, repl); + update_stmt (stmt); + node = cgraph_create_node (repl); + /* ?? For TM_* builtin replacements, can we set this to FALSE?? + Otherwise, do we need to propagate the may_irr bit? */ + node->local.tm_may_enter_irr = true; + return expand_call_tm (region, gsi); + } + gcc_unreachable (); + } if (node->local.tm_may_enter_irr) transaction_subcode_ior (region, GTMA_MAY_ENTER_IRREVOCABLE);