From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71878 invoked by alias); 25 Nov 2015 11:38:07 -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 71864 invoked by uid 89); 25 Nov 2015 11:38:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f170.google.com Received: from mail-yk0-f170.google.com (HELO mail-yk0-f170.google.com) (209.85.160.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 25 Nov 2015 11:38:06 +0000 Received: by ykba77 with SMTP id a77so52419089ykb.2 for ; Wed, 25 Nov 2015 03:38:04 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.129.70.65 with SMTP id t62mr31587831ywa.240.1448451484308; Wed, 25 Nov 2015 03:38:04 -0800 (PST) Received: by 10.37.93.11 with HTTP; Wed, 25 Nov 2015 03:38:04 -0800 (PST) In-Reply-To: <56559121.6040208@redhat.com> 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> <56559121.6040208@redhat.com> Date: Wed, 25 Nov 2015 11:53:00 -0000 Message-ID: Subject: Re: Remove noce_mem_write_may_trap_or_fault_p in ifcvt From: Richard Biener To: Bernd Schmidt Cc: Michael Matz , Jeff Law , GCC Patches , Jakub Jelinek , Sebastian Pop Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg03018.txt.bz2 On Wed, Nov 25, 2015 at 11:44 AM, Bernd Schmidt wrote: > On 11/23/2015 05:05 PM, Michael Matz wrote: >> >> >> 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. > > > Does it also ensure there's no memory barrier in between? I don't think so. Btw, if you want to add this please add a new gimple predicate to identify "memory barrier" (any call or asm with a VDEF). Richard. > > Bernd >