From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 2F8063857B93 for ; Mon, 13 Nov 2023 15:32:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2F8063857B93 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2F8063857B93 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=89.208.246.23 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699889572; cv=none; b=mJc4ve2fbmP6Kgg5+ZmalT6KoVXNGIhkyT8q+iSzhcn22lHbxyrI95XzbxPUHtMlg7LcexrmTXEySvYCyLXug8taRuxhC2NxPca6CHS6QVs7/7+HTxRE+qZkb1SlQh1nZ4lieE9G+g9zPV8FrdlC9qAtaU6uLrTpZFXRr+WZl0U= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699889572; c=relaxed/simple; bh=XwEreOd5zJbFaiq8cUVJX6f88uzBBEgd5LnyCLYXwws=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=SPX8oNqTibPDoykVSLXd/CTD8Wj+HMaSZy8qzjFCMMJibTil0bt7c70paPojAH4yBCtS6O/7aGrC/X+vXuuBRxxIuWp77KEqCgkI/nYja+pvX+Y4WdqTwILO/sa5kbK0/WPMo2J2vBpC5hEBpJEx2dTehFooISFF0V20IYgnxr8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1699889563; bh=XwEreOd5zJbFaiq8cUVJX6f88uzBBEgd5LnyCLYXwws=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=k47DfZEkQYATys7UAFxlE9uWKXBQAIgkrfGchGG6e9dV+19vP2Gc7L03OvyQJtk+m PCuAkAiJmXTMpCJQKBIra+31CE+Cg9lVMAm0MyzhNl+z6I9VOcdL8c9N/648Z6wevU Kd4iRjO3Yjs8JoBSNh6QDD//vvavdPp07Xt+oVv8= Received: from [127.0.0.1] (unknown [IPv6:2001:470:683e::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id 3B89366B06; Mon, 13 Nov 2023 10:32:42 -0500 (EST) Message-ID: <2d10a145fd6c4c8083ce31af5a11414cdfc94174.camel@xry111.site> Subject: Re: [PATCH] LoongArch: Remove redundant barrier instructions before LL-SC loops From: Xi Ruoyao To: chenglulu , gcc-patches@gcc.gnu.org Cc: i@xen0n.name, xuchenghua@loongson.cn, hev Date: Mon, 13 Nov 2023 23:32:40 +0800 In-Reply-To: <72f9180ea473cfbb9ded8ecacea1b08f409ef9f8.camel@xry111.site> References: <20231106113809.1193236-1-xry111@xry111.site> <72f9180ea473cfbb9ded8ecacea1b08f409ef9f8.camel@xry111.site> Autocrypt: addr=xry111@xry111.site; prefer-encrypt=mutual; keydata=mDMEYnkdPhYJKwYBBAHaRw8BAQdAsY+HvJs3EVKpwIu2gN89cQT/pnrbQtlvd6Yfq7egugi0HlhpIFJ1b3lhbyA8eHJ5MTExQHhyeTExMS5zaXRlPoiTBBMWCgA7FiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwMFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQrKrSDhnnEOPHFgD8D9vUToTd1MF5bng9uPJq5y3DfpcxDp+LD3joA3U2TmwA/jZtN9xLH7CGDHeClKZK/ZYELotWfJsqRcthOIGjsdAPuDgEYnkdPhIKKwYBBAGXVQEFAQEHQG+HnNiPZseiBkzYBHwq/nN638o0NPwgYwH70wlKMZhRAwEIB4h4BBgWCgAgFiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwwACgkQrKrSDhnnEOPjXgD/euD64cxwqDIqckUaisT3VCst11RcnO5iRHm6meNIwj0BALLmWplyi7beKrOlqKfuZtCLbiAPywGfCNg8LOTt4iMD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.1 MIME-Version: 1.0 X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, 2023-11-08 at 16:27 +0800, Xi Ruoyao wrote: > On Wed, 2023-11-08 at 09:49 +0800, chenglulu wrote: > >=20 > > =E5=9C=A8 2023/11/6 =E4=B8=8B=E5=8D=887:36, Xi Ruoyao =E5=86=99=E9=81= =93: > > > This is isomorphic to the LLVM changes [1-2]. > > >=20 > > > On LoongArch, the LL and SC instructions has memory barrier semantics= : > > >=20 > > > - LL: + > > > - SC: + > > >=20 > > > But the compare and swap operation is allowed to fail, and if it fail= s > > > the SC instruction is not executed, thus the guarantee of acquiring > > > semantics cannot be ensured. Therefore, an acquire barrier needs to b= e > > > generated when failure_memorder includes an acquire operation. > > >=20 > > > On CPUs implementing LoongArch v1.10 or later, "dbar 0b10100" is an > > > acquire barrier; on CPUs implementing LoongArch v1.00, it is a full > > > barrier.=C2=A0 So it's always enough for acquire semantics.=C2=A0 OTO= H if an > > > acquire semantic is not needed, we still needs the "dbar 0x700" as th= e > > > load-load barrier like all LL-SC loops. > >=20 > > I don't think there's a problem with the logic. I'm also working on=20 > > correcting the content of the atomic functions now, and I'm doing a=20 > > correctness test, including this modification, and I'll email you back > > after the correctness test is completed. >=20 > Ok.=C2=A0 I'd like to note that we now have only 10 days before GCC 14 st= age > 1 ends, so we'd be better hurry. Update: I've bootstrapped and regtested it on a LA664 and there is no regression. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University