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 D8D833857C5A; Thu,  6 Jul 2023 23:49:35 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D8D833857C5A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1688687375;
	bh=15WAOj5LRyZs7Zhdd0ZnudT0n6J5BZ0DBb05Zx2d/dg=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=ycrqPD1oSSjHt8YwIlrWIU9s5L1BTw/NfBru/Xf6aBXlxwXl28i/XiDntskLbO/Hc
	 QOzYXbYRuiCEiLEvMX/qketNCkFDgc0YXwNCVFnJycTBOCLriliG7UveqakkJcgHHG
	 /hITdKhLB5hThLAeXogJXENnYPkGW55LvccF6d+A=
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/110573] branch delay slots are not filled with
 atomic stores
Date: Thu, 06 Jul 2023 23:49:35 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 13.1.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia 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-110573-4-Vym0CiImeA@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110573-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110573-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=3D110573

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Luke Geeson from comment #4)
> I understand treating atomics as volatile has historical precedent but a
> case can be made, at least on modern architectures and with improved
> understanding of models, that atomics are not volatile and more
> optimisations can be applied.
> What do you think?

Not really. The problem is you will need to add a new kind of memory access
type on the RTL level, this is not something which can be done without gett=
ing
things wrong and/or forgetting to update every place that might change
volatileness (including the scheduler which itself getting right is hard).
So treating them as volatile memory access on the RTL level is the easiest =
and
best form here.

Now on the gimple level, they are treated as a function call which itself is
another can of worms.=