From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22770 invoked by alias); 27 Feb 2012 16:44:56 -0000 Received: (qmail 22758 invoked by uid 22791); 27 Feb 2012 16:44:54 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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; Mon, 27 Feb 2012 16:44:37 +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 q1RGiaGj008113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Feb 2012 11:44:36 -0500 Received: from [10.11.11.180] (vpn-11-180.rdu.redhat.com [10.11.11.180]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q1RGiZmI017828; Mon, 27 Feb 2012 11:44:35 -0500 Message-ID: <4F4BB2F3.3010301@redhat.com> Date: Mon, 27 Feb 2012 17:20:00 -0000 From: Andrew MacLeod User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Aldy Hernandez CC: Richard Guenther , Torvald Riegel , Richard Henderson , gcc-patches Subject: Re: [PR51752] publication safety violations in loop invariant motion pass References: <4F46833C.2090808@redhat.com> <4F46AB9D.7050407@redhat.com> <1330089023.2986.3085.camel@triegel.csb> <4F4BADD1.1090407@redhat.com> In-Reply-To: <4F4BADD1.1090407@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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-02/txt/msg01345.txt.bz2 On 02/27/2012 11:22 AM, Aldy Hernandez wrote: > >> Ok. I see. So, I think what would be best is to have a way to check >> whether >> a store/load is part of a transaction - do we have a way to do that >> right now? >> (For example a flag on a gimple stmt?) Then we can simply avoid the LIM > > We do not (*). My patch accumulates that information on demand. I > can certainly add a gimple bit for this, but can't the optimizations > change/rewrite the stores/loads so we lose this information? > I t would seem appropriate to me that in the future, perhaps the CFG could have a flag set for any basic block which is in a transaction... This would make it pretty trivial at all times to tell if a statement is part of a transaction or not. It seems like the process of CFG construction/updating should be able to maintain that info for little cost. (ie, I'd guess it's already making the traversals requires to collect that info) It would certainly be convenient :-) Andrew