From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-help-return-64127-listarch-gcc-help=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 122444 invoked by alias); 12 Sep 2019 15:04:56 -0000
Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-help.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-help/>
List-Post: <mailto:gcc-help@gcc.gnu.org>
List-Help: <mailto:gcc-help-help@gcc.gnu.org>
Sender: gcc-help-owner@gcc.gnu.org
Received: (qmail 122398 invoked by uid 89); 12 Sep 2019 15:04:56 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=
X-HELO: mail-lj1-f180.google.com
Received: from mail-lj1-f180.google.com (HELO mail-lj1-f180.google.com) (209.85.208.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Sep 2019 15:04:54 +0000
Received: by mail-lj1-f180.google.com with SMTP id y5so13122421lji.4        for <gcc-help@gcc.gnu.org>; Thu, 12 Sep 2019 08:04:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=gmail.com; s=20161025;        h=mime-version:references:in-reply-to:from:date:message-id:subject:to         :cc;        bh=/t9acYq4bLcVwbJW86FzJUJhMrmUKqCgQEq6KEcvnFo=;        b=S/UL2Gn9Z4MEUN+ad5KYjU0xe+5EPa5nJYWzzJLvCnIoDdo4iFXDfz2Nexh4MoMrtZ         WU2cvPLSkpLWlmKH93iLdwrMJruZicU0HT2RiXfj18dxSiFL/0fg5nJYO9+Bhitv/IY4         L6ccIr9I5RGeTF3WKffVGGDUz4my5cfseBvFWburK5R7Hh+9YYN1ITfXh7MF30ZjNYm0         iuOq0rxgQckdaUhp7sDBjw6EtedhpKzect2EEDXl+JNjt8F3Sg33MN8hr9OOpxbyO0Y5         4KCYM0ZuPOOpi/BFpbF2C6Mlx0dCfuKD7BNAfFS+aIZfXaXhKEGVwfef0X17aKyZevoU         gruA==
MIME-Version: 1.0
References: <CAF8i9mM5cWGgRO-x9g-5YcgKrgYvhyrJ6g4-uPaHiGepyNjLZQ@mail.gmail.com> <cab5b4e7d4a6a3c43b8ea9e90459b7e3295729c0.camel@t-online.de>
In-Reply-To: <cab5b4e7d4a6a3c43b8ea9e90459b7e3295729c0.camel@t-online.de>
From: William Tambe <tambewilliam@gmail.com>
Date: Thu, 12 Sep 2019 15:04:00 -0000
Message-ID: <CAF8i9mOsN3sXWJyeTWgzZqxeiCV_kpaHRcN7S1LLTm9_-eDasA@mail.gmail.com>
Subject: Re: About machine description for atomic_exchange
To: Oleg Endo <oleg.endo@t-online.de>
Cc: gcc-help <gcc-help@gcc.gnu.org>
Content-Type: text/plain; charset="UTF-8"
X-IsSubscribed: yes
X-SW-Source: 2019-09/txt/msg00042.txt.bz2

Is there an example, not necessarily for atomic_exchange, that I can follow ?

Also, is this behavior related to GCC memory model ? ie:
(MEM_VOLATILE_P (operands[1])) for atomic_exchange always TRUE
regardless of whether the memory operand was declared using
"volatile".

On Tue, Sep 10, 2019 at 4:18 AM Oleg Endo <oleg.endo@t-online.de> wrote:
>
> On Mon, 2019-09-09 at 15:40 -0500, William Tambe wrote:
> > I use documentation for atomic_exchange from:
> > https://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html#Standard-Names
> >
> > When defining machine description for atomic_exchange, I find that GCC
> > mark operands[1] as volatile such that (MEM_VOLATILE_P (operands[1]))
> > returns TRUE; even when the memory operand is not declared using the C
> > keyword "volatile".
> >
> > Is there a way to have atomic_exchange not marking operands[1] as
> > volatile unless the memory operand was declared volatile ?
>
> If you want to distinguish that, one way is to implement all atomic
> patterns in the backedn.  Then you know that those come from
> __atomic__... calls.  In the other patterns, you can then assume that
> MEM_VOLATILE_P must be a mem ref for everything else (that is
> considered a volatile mem ref).
>
> Cheers,
> Oleg
>