From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1601 invoked by alias); 7 Nov 2012 23:02:07 -0000 Received: (qmail 1584 invoked by uid 22791); 7 Nov 2012 23:02:06 -0000 X-SWARE-Spam-Status: No, hits=-6.3 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, 07 Nov 2012 23:01:49 +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 qA7N1nep013305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 7 Nov 2012 18:01:49 -0500 Received: from anchor.twiddle.home (vpn-228-97.phx2.redhat.com [10.3.228.97]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qA7N1mTU026547; Wed, 7 Nov 2012 18:01:48 -0500 Message-ID: <509AE85C.2000107@redhat.com> Date: Wed, 07 Nov 2012 23:02:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 MIME-Version: 1.0 To: Torvald Riegel CC: GCC Patches , Aldy Hernandez Subject: [trans-mem][rfc] Improvements to uninstrumented code paths Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2012-11/txt/msg00666.txt.bz2 I wrote the second of these patches first, and I'm uncertain about the desirability of the first of the patches. While working on the uninstrumented code path bulk patch, I noticed that nested transactions within the copy of the outermost transaction were not being processed for an uninstrumented code path, and so were only receiving an instrumented path. This is clearly less than ideal when considering HTM. Now, it seemed to me that if we're already in an uninstrumented code path, we're extremely likely to want to stay in one. This is certainly true for HTM, as well as when we've selected the serialirr method. I can't think off hand of any other reason we'd be on the uninstrumented code path. Therefore the second patch arranges for all nested transactions in the uninstrumented path to _only_ have uninstrumented paths themselves. While reviewing the results of this second patch in detail, I noticed that nested transactions on the instrumented code paths were not generating both instrumented and uninstrumented code paths. My first reaction was that this was a bug, and so I wrote the first patch to fix it. But as I was reviewing the patch to write the changelog, I began to wonder whether the same logic concerning the original instrumented/ uninstrumented choice applies as well to the instrumented path. Is it ever likely that we'd choose an uninstrumented path for a nested transaction, given that we're already executing the instrumented path for an outer transaction? It now seems to me that the only time we'd switch from instrumented to uninstrumented code path would be during a transaction restart, after having selected to retry with a serialirr method. Which means that I should apply the second patch only, Thoughts? r~