From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19716 invoked by alias); 23 Nov 2015 16:05:47 -0000 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 Received: (qmail 19699 invoked by uid 89); 23 Nov 2015 16:05:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Mon, 23 Nov 2015 16:05:45 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 99875ABFA; Mon, 23 Nov 2015 16:04:33 +0000 (UTC) Date: Mon, 23 Nov 2015 16:07:00 -0000 From: Michael Matz To: Jeff Law cc: Bernd Schmidt , GCC Patches , Jakub Jelinek , Sebastian Pop Subject: Re: Remove noce_mem_write_may_trap_or_fault_p in ifcvt In-Reply-To: <564F6D06.1010806@redhat.com> Message-ID: References: <563CE17F.6090308@t-online.de> <563CF3F0.8010703@redhat.com> <563CF504.2070604@redhat.com> <563CFD92.7020808@redhat.com> <563CFFC0.6020908@redhat.com> <563D170B.3010800@redhat.com> <564CCE73.1090907@redhat.com> <564D0E7C.9070703@redhat.com> <564F297B.8040603@redhat.com> <564F6D06.1010806@redhat.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg02752.txt.bz2 Hi, On Fri, 20 Nov 2015, Jeff Law wrote: > > I'm undecided on whether cs-elim is safe wrt the store speculation vs > > locks concerns raised in the thread discussing Ian's > > noce_can_store_speculate_p, but that's not something we have to consider > > to solve the problem at hand. > I don't think cs-elim is safe WRT locks and such in multi-threaded code. > > In particular it replaces this: > > bb0: > if (cond) goto bb2; else goto bb1; > bb1: > *p = RHS; > bb2: > > with > > bb0: > if (cond) goto bb1; else goto bb2; > bb1: > condtmp' = *p; > bb2: > condtmp = PHI > *p = condtmp; It only does so under some conditions, amongst them if it sees a dominating access to the same memory of the same type (load or store) and size. So it doesn't introduce writes on paths that don't already contain a write, and hence are multi-thread safe. Or, at least, that's the intention. > If *p is a shared memory location, then there may be another writer. > If that writer happens to store something in that location after the > load of *p, but before the store to *p, then that store will get lost in > the transformed pseudo code. Due to the above checking, also the first thread must have been an writer so there already are two writers on the same location, and hence a race is pre-existing. It's only when you introduce a write when there was none whatsoever before (perhaps due to conditionals) that you create a new problem. Ciao, Michael.