From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id C87953832E4C for ; Sat, 29 Jun 2024 02:50:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C87953832E4C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C87953832E4C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.158.5 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719629410; cv=none; b=ma0KRM5NOejtABtU0lz7wLnVxncGUnOXJujaGk7Nb1ru0Sr4CIQRE+O6gEpX2XWBbl/x/u84d0/cuof5G5gvroQydInF0PqJoecT/AbPbz0TPavHC73fpgGM2943quYBptZD5hfSHI1EeJH3O9t29JUO6Cjm/17HA3k/pfTCwCU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719629410; c=relaxed/simple; bh=Dl8qibDuEppOe1bk9NLiUHs4x3jfaVz6+7YWvdYPx1w=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=vVqay73sBxIJPurA8GATNYfIu9rSn4PjYi8uk/TsVrLVYFKxXeepVuktvnmuzKhdJJAERkfVjCWnv8JPCk3VzYN7bJM1iL6XfhER2X77NtvA4jZJW2t2RAtFAlshwvIN1FWGpWlyxTzbDR/4kWUKNimAwxnENOynOfsdZikl654= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0353725.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 45SBMiFe030141; Fri, 28 Jun 2024 12:20:23 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date :from:to:cc:subject:message-id:references:content-type :in-reply-to:mime-version; s=pp1; bh=LVu6hVG581ml3whO60O36FzIUqi E+50/19xxcjEFq0Y=; b=XPooI4tz/c4+KBOlT2ZSsEiQdwkX4wqygAJjkhDJ2zu PCmDuYQmCp/SHJOV3lOajYOGlZM5DTohP3VmIViuWenQKcgujZnm1xZfe9gJiJYS NHQSti6ycdMIGRZYPrQPSJln1EUTNmZ4hsZi93POskX4SfkigCP7ksTlv0/NhElA XYqT+iRNFuMDkZrPua8v8TskIfVkMIWrdVRFx0XNuDO5Ap8mQ0kastghq7onD9Hm yrbdhiZB7M7oqvgjX8ZijPjCCTMLdJXxarpeCrQq5/lXVt9ge4Lx+4RnFwQdttY/ eYNFnPkWh1LXdH/dsnadxHU8E5yCKylisdj9/0tKjxw== Received: from ppma13.dal12v.mail.ibm.com (dd.9e.1632.ip4.static.sl-reverse.com [50.22.158.221]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 401sacghkd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Jun 2024 12:20:23 +0000 (GMT) Received: from pps.filterd (ppma13.dal12v.mail.ibm.com [127.0.0.1]) by ppma13.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 45SBZIZ3019949; Fri, 28 Jun 2024 12:20:22 GMT Received: from smtprelay06.fra02v.mail.ibm.com ([9.218.2.230]) by ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 3yxb5n01v0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Jun 2024 12:20:22 +0000 Received: from smtpav07.fra02v.mail.ibm.com (smtpav07.fra02v.mail.ibm.com [10.20.54.106]) by smtprelay06.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 45SCKJWO32244348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 28 Jun 2024 12:20:21 GMT Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DF63C20043; Fri, 28 Jun 2024 12:20:18 +0000 (GMT) Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C32A920040; Fri, 28 Jun 2024 12:20:18 +0000 (GMT) Received: from li-819a89cc-2401-11b2-a85c-cca1ce6aa768.ibm.com (unknown [9.152.222.48]) by smtpav07.fra02v.mail.ibm.com (Postfix) with ESMTPS; Fri, 28 Jun 2024 12:20:18 +0000 (GMT) Date: Fri, 28 Jun 2024 14:20:18 +0200 From: Stefan Schulze Frielinghaus To: Georg-Johann Lay Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Hard register asm constraint Message-ID: References: <20240524091312.209365-1-stefansf@linux.ibm.com> <511565c6-dae2-4a69-bd3f-5d9ebee6fd29@gjlay.de> <49b1f37f-6644-4f3d-9b7b-671f91326a0b@gjlay.de> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49b1f37f-6644-4f3d-9b7b-671f91326a0b@gjlay.de> X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: euKnwe_9hr8qKOjllH7qy1mSfjQrGl-L X-Proofpoint-GUID: euKnwe_9hr8qKOjllH7qy1mSfjQrGl-L X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-06-28_08,2024-06-28_01,2024-05-17_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 clxscore=1015 mlxscore=0 impostorscore=0 malwarescore=0 lowpriorityscore=0 mlxlogscore=875 phishscore=0 bulkscore=0 priorityscore=1501 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2406140001 definitions=main-2406280088 X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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 Fri, Jun 28, 2024 at 11:46:08AM +0200, Georg-Johann Lay wrote: > Am 27.06.24 um 10:51 schrieb Stefan Schulze Frielinghaus: > > On Thu, Jun 27, 2024 at 09:45:32AM +0200, Georg-Johann Lay wrote: > > > Am 24.05.24 um 11:13 Am 25.06.24 um 16:03 schrieb Paul Koning: > > > > > On Jun 24, 2024, at 1:50 AM, Stefan Schulze Frielinghaus wrote: > > > > > On Mon, Jun 10, 2024 at 07:19:19AM +0200, Stefan Schulze Frielinghaus wrote: > > > > > > On Fri, May 24, 2024 at 11:13:12AM +0200, Stefan Schulze Frielinghaus wrote: > > > > > > > This implements hard register constraints for inline asm. A hard register > > > > > > > constraint is of the form {regname} where regname is any valid register. This > > > > > > > basically renders register asm superfluous. For example, the snippet > > > > > > > > > > > > > > int test (int x, int y) > > > > > > > { > > > > > > > register int r4 asm ("r4") = x; > > > > > > > register int r5 asm ("r5") = y; > > > > > > > unsigned int copy = y; > > > > > > > asm ("foo %0,%1,%2" : "+d" (r4) : "d" (r5), "d" (copy)); > > > > > > > return r4; > > > > > > > } > > > > > > > > > > > > > > could be rewritten into > > > > > > > > > > > > > > int test (int x, int y) > > > > > > > { > > > > > > > asm ("foo %0,%1,%2" : "+{r4}" (x) : "{r5}" (y), "d" (y)); > > > > > > > return x; > > > > > > > } > > > > > > > > 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. > > > > > > > > The other comment is that I didn't see documentation updates to reflect this new feature. > > > > > > > > paul > > > > > > > Stefan Schulze Frielinghaus: > > > > This implements hard register constraints for inline asm. A hard register > > > > constraint is of the form {regname} where regname is any valid register. This > > > > basically renders register asm superfluous. For example, the snippet > > > > > > > > int test (int x, int y) > > > > { > > > > register int r4 asm ("r4") = x; > > > > register int r5 asm ("r5") = y; > > > > unsigned int copy = y; > > > > asm ("foo %0,%1,%2" : "+d" (r4) : "d" (r5), "d" (copy)); > > > > return r4; > > > > } > > > > > > > > could be rewritten into > > > > > > > > int test (int x, int y) > > > > { > > > > asm ("foo %0,%1,%2" : "+{r4}" (x) : "{r5}" (y), "d" (y)); > > > > return x; > > > > } > > > > > > Hi, can this also be used in machine descriptions? > > > > > > It would make some insn handling much simpler, for example in > > > the avr backend. > > > > > > That backend has insns that represent assembly sequences in libgcc > > > which have a smaller register footprint than plain calls. However > > > this requires that such insns have explicit description of which regs > > > go in and out. > > > > > > The current solution uses hard regs, which works, but a proper > > > implementation would use register constraints. I tries that a while > > > ago, and register constraints lead to a code bloat even in places that > > > don't use these constraints due to the zillions of new register classes > > > like R22_1, R22;2, R22_4, R20_1, R20_2, R20_4 etc. that were required. > > > > > > Your approach would allow to use hard register constraints in insns, > > > and so far the only problem is to determine how much hard regs are > > > used by the constraint. The gen tools that generates cc code from md > > > would use the operand's machine mode to infer the number of hard regs. > > > > I have this on my todo list but ignored it for the very first draft. At > > the moment this already fails because genoutput cannot parse the > > constraint format. > > > > In my "alpha draft" I implemented this feature by emitting moves to hard > > registers during expand. This had the limitation that I couldn't > > One problem is that you cannot just introduce hard registers at that > time because a hard reg may live across the sequence, see for example > avr.cc::avr_emit3_fix_outputs() and avr_fix_operands(). Yea I was fearing this. I did some testing on x86_64 and s390 including explicit function calls, sanitizers etc. but of course this was not complete which is why I think that the current draft is more robust. > > > support multiple alternatives in combination with hard-register > > constraints. I'm still not sure whether this is a feature we really > > want or whether it should be rather denied. Anyhow, with this kind of > > implementation I doubt that this would be feasible for machine > > descriptions. I moved on with my current draft where the constraint > > manifests during register allocation. This also allows multiple > > alternatives. I think one of the (major?) advantages of doing it this > > way is that operands are kept in pseudos which means they are > > automagically saved/restored over function boundaries and what not. Or > > in other words, the register constraint manifests at the asm boundary > > which is probably what users expect and should be less error prone > > As far as I know, a local register variable is only supposed to be > loaded to the specified register when the variable is used as an > operand to some inline asm. Only in such asm statements, the > variable will live in the specified register. So "surviving" a > function call is not even a problem to solve with the current local > regvar semantic? I was hoping for this, too, and AFAICS Clang behaves that way but for GCC this isn't the case which is also documented here https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html Warning: In the above example, be aware that a register (for example r0) can be call-clobbered by subsequent code, including function calls and library calls for arithmetic operators on other variables (for example the initialization of p2). In this case, use temporary variables for expressions between the register assignments: This may also lead to subtle bugs like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100908 Cheers, Stefan