From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9894 invoked by alias); 7 Mar 2013 17:25:27 -0000 Received: (qmail 9878 invoked by uid 22791); 7 Mar 2013 17:25:25 -0000 X-SWARE-Spam-Status: No, hits=-7.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,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; Thu, 07 Mar 2013 17:25:15 +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 r27HPEk2030537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 7 Mar 2013 12:25:14 -0500 Received: from reynosa.quesejoda.com (vpn-53-228.rdu2.redhat.com [10.10.53.228]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r27HPC2N029215; Thu, 7 Mar 2013 12:25:13 -0500 Message-ID: <5138CD74.5050100@redhat.com> Date: Thu, 07 Mar 2013 17:25:00 -0000 From: Aldy Hernandez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 MIME-Version: 1.0 To: Richard Henderson CC: gcc-patches Subject: PING: Re: do not pass PR_INSTRUMENTEDCODE if there is no instrumentation References: <51269C36.3070203@redhat.com> <5127AA82.2070108@redhat.com> <512BEA59.2040903@redhat.com> <512BEB2A.9090007@redhat.com> <512CFDC2.5080508@redhat.com> <512E379E.2060906@redhat.com> In-Reply-To: <512E379E.2060906@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2013-03/txt/msg00307.txt.bz2 PING this, or any of my other revisions :) On 02/27/13 10:43, Aldy Hernandez wrote: > On 02/26/13 12:24, Richard Henderson wrote: >> On 02/25/2013 02:52 PM, Aldy Hernandez wrote: >>> I think it's best to do this here at tmmark time, instead of at IPA-tm. >>> Don't we have problems when ipa inlining runs after ipa_tm, thus >>> creating more instrumented code later on? >> >> No, I shouldn't think so. Inlining doesn't change the decision we >> made during >> IPA_TM about whether or not any one transaction doesGoIrr, which is >> the *only* >> bit that's relevant to eliding the uninstrumented code path during >> IPA_TM, and >> thus should be the only bit that's relevant to deciding that the sole >> code path >> is actually supposed to be instrumented or uninstrumented. > > If inlining doesn't change anything then doing it at IPA time is > definitely cleaner. See attached patch. > >> I'm not fond of how much extra code and tests this patch is adding. >> Is it >> really really required? Is my analysis above wrong in some way? > > Well, I know you wanted me to avoid calling ipa_uninstrument_transaction > in ipa_tm_scan_calls_transaction, but the problem is that > ipa_tm_scan_calls_transaction gets called prior to > ipa_tm_transform_transaction which is the one setting the GTMA bits. > > If you're ok with this revision, I could commit it, and figure something > out for eliding the call to ipa_uninstrument_transaction as a followup > patch. I'm thinking either: > > a) Something like the previous patch (which you clearly did not like), > where we remove the edges ex post facto. > > b) Rearrange things somehow so we do ipa_uninstrument_transaction after > ipa_tm_scan_calls_transaction. > > Aldy