From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17834 invoked by alias); 10 Mar 2012 14:15:16 -0000 Received: (qmail 17825 invoked by uid 22791); 10 Mar 2012 14:15:14 -0000 X-SWARE-Spam-Status: No, hits=-6.7 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; Sat, 10 Mar 2012 14:15:00 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q2AEExZR018743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 10 Mar 2012 09:14:59 -0500 Received: from [10.36.5.132] (vpn1-5-132.ams2.redhat.com [10.36.5.132]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q2AEEvUE016190; Sat, 10 Mar 2012 09:14:58 -0500 Subject: Re: [PR51752] publication safety violations in loop invariant motion pass From: Torvald Riegel To: Aldy Hernandez Cc: Richard Guenther , Richard Henderson , gcc-patches In-Reply-To: <4F5A7AB0.6020709@redhat.com> References: <4F46833C.2090808@redhat.com> <4F46AB9D.7050407@redhat.com> <1330089023.2986.3085.camel@triegel.csb> <4F4BADD1.1090407@redhat.com> <4F4D0965.8020108@redhat.com> <4F4D1277.9080206@redhat.com> <4F4D2719.5000209@redhat.com> <4F4D3504.90005@redhat.com> <4F564F7E.3010300@redhat.com> <4F5A7AB0.6020709@redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Sat, 10 Mar 2012 14:15:00 -0000 Message-ID: <1331388897.2986.8735.camel@triegel.csb> Mime-Version: 1.0 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-03/txt/msg00674.txt.bz2 On Fri, 2012-03-09 at 15:48 -0600, Aldy Hernandez wrote: > Torvald is this what you were thinking of? Yes, but with an exit in the else branch or something that can cause x not being read after the condition. I _suppose_ that your original example would be an allowed transformation but just because x would be read anyway independently of flag's value; we can assume data-race freedom, and thus we must be able to read x in a data-race-free way even if flag is false, so flag's value actually doesn't matter. What about modifying the example like below? In this case, if flag2 is true, flag's value will matter and we can't move the load to x before it. Will PRE still introduce "tmp = x + 4" in such an example? Torvald > + __transaction_atomic { > + if (flag) > + y = x + 4; > + else > + // stuff if (flag2) return; > + z = x + 4; > + } > + > + PRE can rewrite this into: > + > + __transaction_atomic { > + if (flag) { > + tmp = x + 4; > + y = tmp; > + } else { > + // stuff > + tmp = x + 4; if (flag2) return; > + } > + z = tmp; > + } > + > + A later pass can move the now totally redundant [x + 4] > + before its publication predicated by "flag": > + > + __transaction_atomic { > + tmp = x + 4; > + if (flag) { > + } else { > + // stuff if (flag2) return; > + } > + z = tmp; > + */