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 0C3D33858417; Mon,  7 Aug 2023 16:19:38 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0C3D33858417
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1691425179;
	bh=9kLBIw1p5nIjEanZGxAKlcPo1qbiwTzjEIR9fqpbEkg=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=UYqRMrrK7c5dCzsGyv5ILw2HHNxIriag/HFOCGce/xzd7OKLTGgLYvIs3REGMQcly
	 IzeCgBGt0Ly/NGQgvY20gTU8ExQjT7fkrA4yPnloxSni4RhlKy7Ea+bul6mdqL8mZr
	 QADio3krQvvC1KxL8z8dNc0CEHlmBrhc/aL+ONM4=
From: "fw at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/110899] RFE: Attributes preserve_most and preserve_all
Date: Mon, 07 Aug 2023 16:19:38 +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: 14.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: fw 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-110899-4-asyJrsVY2Y@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110899-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110899-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=3D110899

--- Comment #8 from Florian Weimer <fw at gcc dot gnu.org> ---
(In reply to Michael Matz from comment #7)
> > > Does the clang implementation take into account the various problemat=
ic
> > > cases that arise when calling a normal function from a (say) preserve=
_all
> > > function
> > > (hint: such call can't usually be done)?
> >=20
> > How so? We need to version the __preserve_most__ attribute with the ISA
> > level, of course.
>=20
> I don't see how that helps.  Imagine a preserve_all function foo that cal=
ls
> printf.  How do you propose that 'foo' saves all parts of the SSE registe=
rs,
> even those that aren't invented yet, or those that can't be touched by the
> current ISA?  (printf might clobber all of these)

Vector registers are out of scope for this.

But lets look at APX. If printf is recompiled to use APX, then it will clob=
ber
the extended register file. If we define __preserve_most__ the way we do in=
 my
psABI proposal (i.e., *not* as everything but %r11), the extended APX regis=
ters
are still caller-saved. We will have to introduce a __preserve_most_apx__
attribute and a different psABI specification that says that the new APX
registers are callee-saved, too.

(These details are the main reason why I want this in the psABI documentati=
on.
This stuff is out there and will be used, so let's make sure that it's some=
what
reasonable.)=