From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <xry111@mengyan1223.wang>
Received: from mengyan1223.wang (mengyan1223.wang [89.208.246.23])
 by sourceware.org (Postfix) with ESMTPS id E90BF385841F
 for <gcc-help@gcc.gnu.org>; Thu, 24 Feb 2022 20:05:39 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E90BF385841F
Received: from [IPv6:240e:358:1147:5a00:dc73:854d:832e:4] (unknown
 [IPv6:240e:358:1147:5a00:dc73:854d:832e:4])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature ECDSA (P-384))
 (Client did not present a certificate)
 (Authenticated sender: xry111@mengyan1223.wang)
 by mengyan1223.wang (Postfix) with ESMTPSA id 4F25165CF1;
 Thu, 24 Feb 2022 15:05:34 -0500 (EST)
Message-ID: <1bb8ab09556727917d07ec31683996bb7e493fa6.camel@mengyan1223.wang>
Subject: Re: Libatomic 16B
From: Xi Ruoyao <xry111@mengyan1223.wang>
To: Satish Vasudeva <satish.vasudeva@cohesity.com>
Cc: gcc-help@gcc.gnu.org
Date: Fri, 25 Feb 2022 04:05:28 +0800
In-Reply-To: <CABp-VvJDTMyZedDnVKyn1q5oy5TkOGF5Ui=EKoBYnPVwp9vFxQ@mail.gmail.com>
References: <CABp-Vv+QQCri1miq9xr0Ug_Fyb-LxBTbJR-GXDb2YgXKrA1LJA@mail.gmail.com>
 <6349834d9ea31f579b04ba9215b6449ce13f008e.camel@mengyan1223.wang>
 <CABp-VvJDTMyZedDnVKyn1q5oy5TkOGF5Ui=EKoBYnPVwp9vFxQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3031.5 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, SPF_HELO_PASS,
 SPF_PASS, TXREP,
 T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
 server2.sourceware.org
X-BeenThere: gcc-help@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-help mailing list <gcc-help.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-help/>
List-Post: <mailto:gcc-help@gcc.gnu.org>
List-Help: <mailto:gcc-help-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Feb 2022 20:05:42 -0000

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).
-- 
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University