From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by sourceware.org (Postfix) with ESMTPS id 2EA293858C3A for ; Thu, 4 Nov 2021 08:58:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2EA293858C3A Received: by mail-ed1-x52f.google.com with SMTP id v11so16228338edc.9 for ; Thu, 04 Nov 2021 01:58:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gjLGn6EVQHhQj5EvBZB9cO5L2H9nIU18VIvn8mQtNBs=; b=GZfEepQHkBaCANnli74DP86RLVThVRPlxcwsch6l/LL51jyCSfCoXXWN78XA7yAbD3 PHJbEOV7wec/qxRJcdHF7P3m4F5NIjYwWt1HiOkLPZUxOyfwfg2ffrmftESi6G4hzAft FJEWCsBBcs9/zsvSgzBDRr2R4BjtbKofJKn/LXSH47jBNnnPPv8De4cQKD/hLX3ewRo1 AkADkKoLntm/LJzmFvjLKme9ZJuUe/q3isgZlFV/YccX58e2lw6eX0P1PL9pgANVLJFC rx2GLhyV5NmY9kS3GvgZ8GoD1IKpqKyg8kRqciY9jJt9qH+1VBwCvplLDUZpxiF0SKcn AsqA== X-Gm-Message-State: AOAM532AP0fHaj3POSrrbwmQvbcc+1cU4Gr4jPPmQnazsbnlXubCiH1v BygoEnb5z8vmXJ1GCalO7eCq1D6vnN1JUblD6z2xX6GTdML0Pg== X-Google-Smtp-Source: ABdhPJzFkWxEctuoBt4EDVnj2F0O4F3a/dKAab/xv3RQKwMpGTM/Wkz0FlwhEN4bju0ZVhitbR7zA6xzxiURzoe3otw= X-Received: by 2002:aa7:c501:: with SMTP id o1mr66776538edq.99.1636016298234; Thu, 04 Nov 2021 01:58:18 -0700 (PDT) MIME-Version: 1.0 References: <20211103150415.1211388-1-hjl.tools@gmail.com> <87v91917mb.fsf@igel.home> In-Reply-To: From: Oleh Derevenko Date: Thu, 4 Nov 2021 10:58:07 +0200 Message-ID: Subject: Re: [PATCH] x86: Optimize atomic_compare_and_exchange_[val|bool]_acq [BZ #28537] To: "H.J. Lu" Cc: Andreas Schwab , Arjan van de Ven via Libc-alpha , Arjan van de Ven Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2021 08:58:21 -0000 Hi, On Thu, Nov 4, 2021 at 12:12 AM H.J. Lu wrote: > > On Wed, Nov 3, 2021 at 1:38 PM Oleh Derevenko wrote: > > > > To force a compiler to re-read the value it is sufficient to take a > > pointer to the storage, cast it to volatile and read via that > > pointer-to-volatile. > > Like this? > > #define atomic_compare_and_exchange_val_acq(mem, newval, oldval) \ > ({ volatile __typeof (*(mem)) *memp = (mem); \ > __typeof (*(mem)) oldmem = *memp, ret; \ > ret = (oldmem == (oldval) \ > ? __sync_val_compare_and_swap (mem, oldval, newval) \ > : oldmem); \ > ret; }) > #define atomic_compare_and_exchange_bool_acq(mem, newval, oldval) \ > ({ volatile __typeof (*(mem)) *memp = (mem); \ > __typeof (*(mem)) oldmem = *memp; \ > int ret; \ > ret = (oldmem == (oldval) \ > ? !__sync_bool_compare_and_swap (mem, oldval, newval) \ > : 1); \ > ret; }) > Yes. The only problem is that I'm not sure if that extra volatile will not cause a compilation warning/error if the type already had the volatile modifier in it. Also, another problem, blindly taking __typeof (*(mem)) oldmem = ... could declare the "oldmem" variable with const and/or volatile (depending on the actual parameter to the macro) and make either an assignment to const (a compile error) or an assignment to volatile (unnecessary forced store into memory with following retrieval from there).