From patchwork Wed Feb 20 15:35:59 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aldy Hernandez X-Patchwork-Id: 222105 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 A2C1E2C007C for ; Thu, 21 Feb 2013 02:36:19 +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=1361979380; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=iV7CVjY j6e4BQ27WsZ1GNVSv/ao=; b=Tt3NbB4la3YsNKAlxtsesIzH+QusZTJLH+Zu04B g2/apIo9h7fEwgkOOux86aPE4nur3fpgeUpp/g4AIEKY98KLHqW6nf1bgbNPjJnD V+4enqMp/UyfMZiaSAN2xjpa0YZg7yzFCSt/w2HPbQIdKPqhhEhTCJFtGvtO+5P2 RbJQ= 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:CC:Subject:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=MjuXb3I2C6ynBEmzwjlKBXsfi4iYUNs4pG7YPTy3F7xEnYaFHF3Dw+1K3QlhaK BC9aei6/JNz4aExQBPYIsxcMvVyOkiAgcHTlwgoKTF9jxjvDRutKj+xqId7DSQ/e lcUFltUTi8wggBBZwL7rv6ltdK4qW4aA2XQWXRZRX/Ju0=; Received: (qmail 29054 invoked by alias); 20 Feb 2013 15:36:11 -0000 Received: (qmail 28983 invoked by uid 22791); 20 Feb 2013 15:36:10 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_SPAMHAUS_DROP, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, RP_MATCHES_RCVD, SPF_HELO_PASS 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; Wed, 20 Feb 2013 15:36:01 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r1KFa0Bn029409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 20 Feb 2013 10:36:00 -0500 Received: from houston.quesejoda.com (vpn-50-109.rdu2.redhat.com [10.10.50.109]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r1KFZxge025100; Wed, 20 Feb 2013 10:36:00 -0500 Message-ID: <5124ED5F.5050302@redhat.com> Date: Wed, 20 Feb 2013 09:35:59 -0600 From: Aldy Hernandez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Richard Henderson CC: gcc-patches Subject: [PR middle-end/56108] handle transactions with ASMs in the first block 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 In the following test, the first statement of a relaxed transaction is an inline asm: __transaction_relaxed { __asm__(""); } Since we bypass inserting BUILT_IN_TM_IRREVOCABLE at the beginning of transactions that are sure to be irrevocable, later when we try to expand the transaction, we ICE when we encounter the inline asm. Currently, we bypass the TM_IRREVOCABLE call here: for (region = d->all_tm_regions; region; region = region->next) { /* If we're sure to go irrevocable, don't transform anything. */ if (d->irrevocable_blocks_normal && bitmap_bit_p (d->irrevocable_blocks_normal, region->entry_block->index)) { transaction_subcode_ior (region, GTMA_DOES_GO_IRREVOCABLE); transaction_subcode_ior (region, GTMA_MAY_ENTER_IRREVOCABLE); continue; } If I understand this correctly, ideally a transaction marked as doesGoIrrevocable shouldn't bother instrumenting the statements inside, since the runtime will go irrevocable immediately. In which case, we can elide the instrumentation altogether as the attached patch does. If my analysis is correct, then testsuite/gcc.dg/tm/memopt-1.c would surely go irrevocable, thus requiring no instrumentation, causing the memory optimizations to get skipped altogether. In which case, it's best to mark the function calls as safe, so they don't cause the transaction to become obviously irrevocable. Is this correct? If so, OK? PR middle-end/56108 * trans-mem.c (execute_tm_mark): Do not expand transactions that are sure to go irrevocable. testsuite/ * gcc.dg/tm/memopt-1.c: Declare functions transaction_safe. diff --git a/gcc/testsuite/gcc.dg/tm/memopt-1.c b/gcc/testsuite/gcc.dg/tm/memopt-1.c index b78a6d4..c5ac5ce 100644 --- a/gcc/testsuite/gcc.dg/tm/memopt-1.c +++ b/gcc/testsuite/gcc.dg/tm/memopt-1.c @@ -2,8 +2,8 @@ /* { dg-options "-fgnu-tm -O -fdump-tree-tmmemopt" } */ long g, xxx, yyy; -extern george() __attribute__((transaction_callable)); -extern ringo(long int); +extern george() __attribute__((transaction_safe)); +extern ringo(long int) __attribute__((transaction_safe)); int i; f() diff --git a/gcc/testsuite/gcc.dg/tm/pr56108.c b/gcc/testsuite/gcc.dg/tm/pr56108.c new file mode 100644 index 0000000..81ff574 --- /dev/null +++ b/gcc/testsuite/gcc.dg/tm/pr56108.c @@ -0,0 +1,9 @@ +/* { dg-do compile } */ +/* { dg-options "-fgnu-tm -O" } */ + +int +main() +{ + __transaction_relaxed { __asm__(""); } + return 0; +} diff --git a/gcc/trans-mem.c b/gcc/trans-mem.c index dd3918e..71eaa44 100644 --- a/gcc/trans-mem.c +++ b/gcc/trans-mem.c @@ -2859,8 +2859,23 @@ execute_tm_mark (void) // Expand memory operations into calls into the runtime. // This collects log entries as well. FOR_EACH_VEC_ELT (bb_regions, i, r) - if (r != NULL) - expand_block_tm (r, BASIC_BLOCK (i)); + { + if (r != NULL) + { + if (r->transaction_stmt) + { + unsigned sub = gimple_transaction_subcode (r->transaction_stmt); + + /* If we're sure to go irrevocable, there won't be + anything to expand, since the run-time will go + irrevocable right away. */ + if (sub & GTMA_DOES_GO_IRREVOCABLE + && sub & GTMA_MAY_ENTER_IRREVOCABLE) + continue; + } + expand_block_tm (r, BASIC_BLOCK (i)); + } + } bb_regions.release ();