From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-h2p-567354.sys.comcast.net (resqmta-h2p-567354.sys.comcast.net [IPv6:2001:558:fd02:2446::5]) by sourceware.org (Postfix) with ESMTPS id 3173B383E512 for ; Wed, 26 Jun 2024 15:10:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3173B383E512 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=comcast.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=comcast.net ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3173B383E512 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:558:fd02:2446::5 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719414645; cv=none; b=hwKUg++BRUnMKHyyL3UeV9DcTeNnd1dCT5x2M3skGwuaiCDYvLhZ63so//pQOrw/j5tT/Y4l2yj7FmN1HdYC6uogC72UYynM2FvEzHtiCoQG3NCjlyXdAfiXg/Bkj636dDGpUB7EdQtG1/WeUWU5A1Te5V49OfggVBuyFsQqrjQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719414645; c=relaxed/simple; bh=Te2f4MDJ93jQcH4dps/kL52ufgPaLFJlebZnM2hN/G0=; h=DKIM-Signature:Mime-Version:Subject:From:Date:Message-Id:To; b=PsuF6DTBF1Yrj481907a4w6SMsuaJ4crpicKygqWni5UBS6png6qPHLB+buEFTw3o2dOcAmPHB2+1Dq7akJYp9hvOxigQLYj5fEmjl9pfQUB3euAitLVFdfp9AGBKQqKZZk3SlWqwzBH+itjqRAukaGljRYnfZN2ldarLun6g8g= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from resomta-h2p-554995.sys.comcast.net ([96.102.179.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 256/256 bits) (Client did not present a certificate) by resqmta-h2p-567354.sys.comcast.net with ESMTPS id MRFPsQaQyw3wSMUIDsaLdW; Wed, 26 Jun 2024 15:10:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1719414641; bh=ttZCz0x890doRoJk0R4st8RLSt0tNFruWUXTCostREk=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To:Xfinity-Spam-Result; b=gGDFeNkVZ+0tcDODjm40lxCTLgtwaz8Qs3uQRFzqqodUJB3cKI+HqHcb8sfIxYvZF AHmJJ1tLxK2rnrwpYHjoJ8KVC3QA/7i6RqS4wd6YtZHjUzLzUC9iak2pnjRp0gHRNy ReyecQlxFrJda+OpXSYOv18RlI4SVE+QwXknSZut/0HhxZ7+V7vX3sBJqp+Rk1/kae Tt/ow75OPTVffMSpJLlIUWBj65mDsBRlKaj0UcUI9PZCcUEWi2GA0uAEU8oKd+Sgn9 KG90OyVVopIasANRjxVhLsl6uw6Re93YcLZ1QzQcqVB4CtEBfCg5vkPYV55gfLUJX2 7xt+8gFPjCV5w== Received: from smtpclient.apple ([73.60.223.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resomta-h2p-554995.sys.comcast.net with ESMTPSA id MUIAsTENjMMG3MUIBsCz8o; Wed, 26 Jun 2024 15:10:41 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\)) Subject: Re: [PATCH] Hard register asm constraint From: Paul Koning In-Reply-To: Date: Wed, 26 Jun 2024 11:10:38 -0400 Cc: gcc-patches@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20240524091312.209365-1-stefansf@linux.ibm.com> <0701EC44-8E0B-4584-B72F-D4251C902B32@comcast.net> To: Stefan Schulze Frielinghaus X-Mailer: Apple Mail (2.3696.120.41.1.8) X-CMAE-Envelope: MS4xfI5cRkZRlup9wsbKhaDoMKmNGFgchNGqAZ5ipCq1CoxHCKn3UJH4LB5xjkdVWTsXpQb3gXRLRTNoiePPU1RL7ziXhQ4mR4/v+n14YRdruNocvDFu01Mz 7Hqsykt5avRXSp4j4cZIwi6/CsWlpb+FMMLmu2PT7Co+WQ7UNyIu8thCG0bOhBudeB+sOQCld+5xYuQcRVn89LIfQdviUtdBlzHbNKNBsHzVcFJn73m6rgBF X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham 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 Jun 26, 2024, at 8:54 AM, Stefan Schulze Frielinghaus = wrote: >=20 > On Tue, Jun 25, 2024 at 01:02:39PM -0400, Paul Koning wrote: >>=20 >>=20 >>> On Jun 25, 2024, at 12:04 PM, Stefan Schulze Frielinghaus = wrote: >>>=20 >>> On Tue, Jun 25, 2024 at 10:03:34AM -0400, Paul Koning wrote: >>>>=20 >>>>>>> ... >>>>>>> could be rewritten into >>>>>>>=20 >>>>>>> int test (int x, int y) >>>>>>> { >>>>>>> asm ("foo %0,%1,%2" : "+{r4}" (x) : "{r5}" (y), "d" (y)); >>>>>>> return x; >>>>>>> } >>>>=20 >>>> I like this idea but I'm wondering: regular constraints specify = what sort of value is needed, for example an int vs. a short int vs. a = float. The notation you've shown doesn't seem to have that aspect. >>>=20 >>> As Maciej already pointed out the type of the expression should = suffice. >>> My assumption was that an asm can deal with a value as is or its >>> promoted value. At least for integer values this should be fine and >>> AFAICS is also the case for simple constraints like "r" which do not >>> define any mode. I've probably overseen something but which = constraint >>> differentiates between int vs short? However, you have a good point >>> with this and I should test this more. >>=20 >> I thought there was but I may be confused. On the other hand, there = definitely are (machine dependent) constraints that distinguish, say, = float from integer registers; pdp11 is an example. If you were to use = an "a" constraint, that means a floating point register and the compiler = will detect attempts to pass non-float operands ("Inconsistent operand = constraints..."). >>=20 >> I see that the existing "register int ..." syntax appears to check = that the register is the right type for the data type given for it, so = for example on pdp11,=20 >>=20 >> register int ac1 asm ("ac1") =3D i; >>=20 >> fails ("register ... isn't suitable for data type"). I assume your = new syntax would perform the same check and produce roughly the same = error message. You might verify that. On pdp11, trying to use, for = example, "r0" for a float, or "ac0" for an int, would produce that = error. >=20 > Right, so far I don't error out here which I will change. It = basically > results in bit casting floats to ints currently. That would be bad. For one thing, a PDP11 float doesn't fit in an = integer register. That also brings up another point (which applies to more mainstream = targets as well): for data types that require multiple registers, say a = register pair for a double length value, how is that handled? One = possible answer is to reject that. Another would be to load a register = pair. This case applies to a "long int" on pdp11, or 32 bit MIPS, and probably = a bunch of others. paul