From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-398716-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 68707 invoked by alias); 22 May 2015 17:04:37 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 68697 invoked by uid 89); 22 May 2015 17:04:36 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mail-ie0-f170.google.com
Received: from mail-ie0-f170.google.com (HELO mail-ie0-f170.google.com) (209.85.223.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 22 May 2015 17:04:35 +0000
Received: by iepj10 with SMTP id j10so35651679iep.3        for <gcc-patches@gcc.gnu.org>; Fri, 22 May 2015 10:04:33 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.33.9 with SMTP id h9mr3803001ioh.1.1432314273311; Fri, 22 May 2015 10:04:33 -0700 (PDT)
Received: by 10.36.108.21 with HTTP; Fri, 22 May 2015 10:04:33 -0700 (PDT)
In-Reply-To: <555F49FF.1070402@foss.arm.com>
References: <555F1143.4070606@foss.arm.com>	<555F11B6.1070001@foss.arm.com>	<555F31CF.6060201@redhat.com>	<CAGWvnykzukDM2aG_QmbeCyOh7+u6xF8snOc13GUHG2RULoQU-g@mail.gmail.com>	<555F3D09.2070700@redhat.com>	<555F49FF.1070402@foss.arm.com>
Date: Fri, 22 May 2015 17:48:00 -0000
Message-ID: <CAGWvnymOEa42ki94XgXLES7sf5CCD-KDaZy8AHsYOYpYuvSPjA@mail.gmail.com>
Subject: Re: [RFC / CFT] PR c++/66192 - Remove TARGET_RELAXED_ORDERING and use load acquires.
From: David Edelsohn <dje.gcc@gmail.com>
To: Ramana Radhakrishnan <ramana.radhakrishnan@foss.arm.com>, 	Steve Munroe <munroesj@linux.vnet.ibm.com>
Cc: Jason Merrill <jason@redhat.com>, "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>, 	Jim Wilson <wilson@tuliptree.org>, Steve Ellcey <sellcey@mips.com>, 	Richard Henderson <rth@redhat.com>
Content-Type: text/plain; charset=UTF-8
X-SW-Source: 2015-05/txt/msg02154.txt.bz2

On Fri, May 22, 2015 at 11:23 AM, Ramana Radhakrishnan
<ramana.radhakrishnan@foss.arm.com> wrote:

> So on powerpc where targetm.guard_mask_bit is false - this is what I see.
>
>
> {
>   static int * p;
>
>     static int * p;
>   if (<<cleanup_point (unsigned char) *(char *) &(long long int)
> __atomic_load_8 (&_ZGVZ1fvE1p, 2) == 0>>)
>     {
>       if (<<cleanup_point __cxa_guard_acquire (&_ZGVZ1fvE1p) != 0>>)
>         {
>           <<cleanup_point <<< Unknown tree: expr_stmt
>   TARGET_EXPR <D.2846, 0>;, p = (int *) operator new (4);;, D.2846 = 1;;,
> __cxa_guard_release (&_ZGVZ1fvE1p); >>>>>;
>         }
>     }
>   return <retval> = p;
> }
>
> with the following output - David - is this what you would expect ?
>
>
> 0:      addis 2,12,.TOC.-0b@ha
>         addi 2,2,.TOC.-0b@l
>         .localentry     _Z1fv,.-_Z1fv
>         mflr %r0
>         std %r30,-16(%r1)
>         std %r31,-8(%r1)
>         .cfi_register 65, 0
>         .cfi_offset 30, -16
>         .cfi_offset 31, -8
>         addis %r30,%r2,_ZGVZ1fvE1p@toc@ha
>         addi %r30,%r30,_ZGVZ1fvE1p@toc@l
>         std %r0,16(%r1)
>         stdu %r1,-64(%r1)
>         .cfi_def_cfa_offset 64
>         .cfi_offset 65, 16
>         addis %r10,%r2,_ZGVZ1fvE1p@toc@ha               # gpr load fusion,
> type long
>         ld %r10,_ZGVZ1fvE1p@toc@l(%r10)
>         cmpw %cr7,%r10,%r10
>         bne- %cr7,$+4
>         isync
>         rlwinm %r9,%r10,0,0xff
>         std %r10,32(%r1)
>         cmpwi %cr7,%r9,0
>         beq %cr7,.L11
> .L9:
>         addi %r1,%r1,64
>         .cfi_remember_state
>         .cfi_def_cfa_offset 0
>         addis %r3,%r2,_ZZ1fvE1p@toc@ha          # gpr load fusion, type long
>         ld %r3,_ZZ1fvE1p@toc@l(%r3)
>         ld %r0,16(%r1)
>         ld %r30,-16(%r1)
>         ld %r31,-8(%r1)
>         mtlr %r0
>         .cfi_restore 65
>         .cfi_restore 31
>         .cfi_restore 30
>         blr
>         .p2align 4,,15
> .L11:
>         .cfi_restore_state
>         mr %r3,%r30

It looks reasonable, but we really need to examine the code produced
by the final version of the patch for some examples.

Thanks, David