From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id A000F3858291; Fri,  3 Feb 2023 17:14:59 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A000F3858291
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1675444499;
	bh=XCGv8fiq3kaxthsRGLK/USgV5V/pT/S7L7iHVjZtD7c=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=I0b3NlAQSBUnvvNnhyvGHtwpuKnkaMzP8BK8qCpFzGgJfs8qZgLp7Hs0wJqQOF4GE
	 dEXmp+tr8WqsRFYUcquhglElk/Nr7LzEYWH49Ha8zdoUCxd+gvzKo48XCtxnNm528l
	 SAG7dnaGfSsNV96VdnM6nU3hGRP/dDQAIT9fX0BY=
From: "s_gccbugzilla at nedprod dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/108659] Suboptimal 128 bit atomics codegen on AArch64
 and x64
Date: Fri, 03 Feb 2023 17:14:59 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 12.2.1
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: s_gccbugzilla at nedprod dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-108659-4-wiMWCUsDbN@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108659-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108659-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108659

--- Comment #3 from Niall Douglas <s_gccbugzilla at nedprod dot com> ---
> AMD has guaranteed it, but there is still VIA and Zhaoxin and while we ha=
ve some statement from the latter, I'm not sure it is enough and we don't h=
ave anything from VIA.  See PR104688 for details.

I'm wondering if a compiler opt out flag like -no-msseatomic16 to turn off =
use
of SSE for 128 bit atomics wouldn't be an idea? Given the small market shar=
e of
those CPU vendors, seems a shame to hold up implementation.

(Also, if you do turn it on by default and advertise that widely, I suspect
those vendors will hurry up with their documentation)

> FWIW, the GCC codegen for aarch64 is at https://godbolt.org/z/qvx9484nY (=
arm and aarch64 are different targets). It emits a call to libatomic, which=
 for GCC 13 will use a lockless implementation when possible at runtime, se=
e g:d1288d850944f69a795e4ff444a427eba3fec11b

Thanks for the catch, my mistake. It would seem the codegen is similarly
inferior to the codegen from clang for both aarch64 and x64.

You may be interested in reading https://reviews.llvm.org/D110069. It wante=
d to
have LLVM generate a 128 bit AArch64 CAS for atomics. LLVM merged that chan=
ge,
it'll be in the next release.=