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 925D03858C52; Fri,  3 Feb 2023 21:51:34 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 925D03858C52
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1675461094;
	bh=LB4JCUYN+hNMm+wEKoploiP5RnBOveEWXJnN+p9FdJk=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=cLeNKcCR9DaoUMUYZ/YghPqVtOOQt53wdxlbx+rcqqgsp6jiG8JN0M3vLzD7xsbaG
	 oEMYqpWcP2oSIedqUMkFFiI4wi4wPM9skU1IDnEvKs71btxLQxpVtGnAj8CqJO9ltn
	 Rpne3s3OALJTfrRuLEPCl+3zAhaJGC890LFRaxFU=
From: "wilco at gcc dot gnu.org" <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 21:51:34 +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: wilco at gcc dot gnu.org
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-Q18hc3lqiw@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 #8 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Niall Douglas from comment #7)
> (In reply to Andrew Pinski from comment #4)
> > (In reply to Niall Douglas from comment #3)=20
> > > You may be interested in reading https://reviews.llvm.org/D110069. It=
 wanted
> > > to have LLVM generate a 128 bit AArch64 CAS for atomics. LLVM merged =
that
> > > change, it'll be in the next release.
> >=20
> > Using CAS for atomic load is not valid thing to do ...
> > Because atomic load from constant rodata needs to work.
> > LLVM breaks this case as they don't care about it. GCC does though.
>=20
> I've heard that argument before, and I've always wondered why _Atomic128
> types couldn't have an attribute which applies attribute section to their
> static const variable incarnations to force them into r/w memory. That wo=
uld
> also solve the LLVM issue. Said attribute is not unuseful in general
> actually, it would help avoid having to mess with mprotect to apply copy =
on
> write perms on regions in .rodata when you need to modify static const
> variable values.
>=20
> I don't think that the standard *guarantees* that static const variables =
go
> into read only memory, and besides, before C23 128 bit integers weren't
> supported anyway so one could argue as a proprietary extension (__int128)
> you get proprietary special casing.

Yes that sounds like a reasonable approach. There will language lawyers that
say it must also work on mmap after mprotect of course, but that seems even
more unlikely in the real world...

I believe that the vast majority of developers just want 128-bit atomics to
work efficiently without locks when possible.

Currently various packages are forced to create 128-bit atomics using inline
assembler - and that seems a much worse hack than supporting lock-free atom=
ics
in the compiler.=