From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26338 invoked by alias); 16 Oct 2012 23:54:14 -0000 Received: (qmail 26330 invoked by uid 22791); 16 Oct 2012 23:54:14 -0000 X-SWARE-Spam-Status: No, hits=-7.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,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; Tue, 16 Oct 2012 23:54:08 +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 q9GNs70Q022865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Oct 2012 19:54:07 -0400 Received: from reynosa.quesejoda.com (vpn-9-158.rdu.redhat.com [10.11.9.158]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q9GNs5AE014961; Tue, 16 Oct 2012 19:54:06 -0400 Message-ID: <507DF39C.4060609@redhat.com> Date: Wed, 17 Oct 2012 00:33:00 -0000 From: Aldy Hernandez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Jakub Jelinek CC: Ian Lance Taylor , gcc-patches , Richard Guenther , Ian Lance Taylor , Andrew MacLeod Subject: Re: [path] PR 54900: store data race in if-conversion pass References: <507C015F.2090508@redhat.com> <20121016172820.GK584@tucnak.redhat.com> In-Reply-To: <20121016172820.GK584@tucnak.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: 2012-10/txt/msg01608.txt.bz2 On 10/16/12 13:28, Jakub Jelinek wrote: > I see another problem with noce_can_store_speculate_p, the return false; > checks. The search for a store to exactly that location can be done > just on post dominator bbs, but I wonder how you can avoid looking for > volatile insns or non-const/pure calls (or insns that may modify > the address) also in other bbs. > What if there is: > location of considered if-conversion on mem > if (some_condition) > call (); > mem = something; Are we not currently being conservative in the current code and returning false once we see a volatile or a non-const call? > ? We only walk immediate post-dominators, so look at the bb containing > mem = something;, but I think a call/volatile insn/modification of mem's > address is problematic in any bb on any path in between test_bb and > the post-dominator on which the write has been found. > > Jakub >