From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id 474713858414 for ; Thu, 24 Feb 2022 20:38:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 474713858414 Received: by mail-ej1-x634.google.com with SMTP id qk11so6850983ejb.2 for ; Thu, 24 Feb 2022 12:38:35 -0800 (PST) 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=jCthcWtov/JrPenEE/1FAHT8IMtGeF8q2uJJihsjXwY=; b=0YZpdcivWIsz4bS195E9jsfwpBFgYzIfvK3frqJCrtkr/1NaEfB99RhnxdTTHblwJn nOEcEceI1fffGoq5rC39fxJbZ9GZJGn5n9aNkXimUCN38RhKqjQQvhDKPTlWx78cIL5z u4jyXBDKW/jOOxJZoHp08BJ/2/cB4AgztBgipyKsrRNfAHUkSWG1vDgp7m37DUXyQa79 dXl9lQbyWuouSsBDCdrKVBX6KipSnlvukH6nzdhTNPNznBTtpvw+u7yA2NSLtW5VqXiw C9KrVgphfpvQU12K/JyzxGcDl+2pYPR5EGShPps9Wj1kcuaV5dqFEiQvRq17+6rDfj94 74NA== X-Gm-Message-State: AOAM533oscYP9mvMOJmgtCWR+KpkhGNlURCkS5UL2TY0MeAalrjHYlu4 o63nhf/KpH3VtP864hpf7TS5dfMLw7SBk01X49JhpA== X-Google-Smtp-Source: ABdhPJzdboREidY809Vmyg/j89BiQ5hfy/WiCJSancJGwt9uAeCdGMnaViArPHsiehbJ+zvEclOcdu+r3UPejWRSbS0= X-Received: by 2002:a17:906:71d5:b0:6a7:fd56:e9ad with SMTP id i21-20020a17090671d500b006a7fd56e9admr3479805ejk.178.1645735114163; Thu, 24 Feb 2022 12:38:34 -0800 (PST) MIME-Version: 1.0 References: <6349834d9ea31f579b04ba9215b6449ce13f008e.camel@mengyan1223.wang> <1bb8ab09556727917d07ec31683996bb7e493fa6.camel@mengyan1223.wang> <20220224201334.GQ614@gate.crashing.org> In-Reply-To: <20220224201334.GQ614@gate.crashing.org> From: Satish Vasudeva Date: Thu, 24 Feb 2022 12:38:46 -0800 Message-ID: Subject: Re: Libatomic 16B To: Segher Boessenkool Cc: Xi Ruoyao , gcc-help@gcc.gnu.org X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 20:38:36 -0000 Thanks for the comments. Please let into this intel architecture manual , section 8.1.1 https://cdrdv2.intel.com/v1/dl/getContent/671190 I think Intel claims 16B operations are atomic , unless I am missing something. On Thu, Feb 24, 2022 at 12:16 PM Segher Boessenkool < segher@kernel.crashing.org> wrote: > On Fri, Feb 25, 2022 at 04:05:28AM +0800, Xi Ruoyao via Gcc-help wrote: > > On Thu, 2022-02-24 at 11:35 -0800, Satish Vasudeva wrote: > > > Thanks for the response. > > > > > > Looking further into libatomic library code, I do see 16B move > > > instructions have been used for atomic_exchange code like below. Just > > > wondering why it is not generating a intrinsic __atomic_load_16 using > > > this instruction. > > > > > > movdqa0x0(%rbp),%xmm0 > > > > Because both Intel and AMD have not claimed "this is atomic". In > > __atomic_exchange movdqa is used as a normal data move instruction > > (actually, GCC optimized memcpy calls in libatomic code to this). > > Yup. Even on cores where this is atomic internally it is not atomic > when used on a system with a 64-bit (or 72-bit) memory bus. > > > Segher >