From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23714 invoked by alias); 21 Feb 2019 03:03:55 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 23677 invoked by uid 89); 21 Feb 2019 03:03:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,KHOP_DYNAMIC,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1212 X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 21 Feb 2019 03:03:54 +0000 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1L2xDGS117175 for ; Wed, 20 Feb 2019 22:03:52 -0500 Received: from e12.ny.us.ibm.com (e12.ny.us.ibm.com [129.33.205.202]) by mx0a-001b2d01.pphosted.com with ESMTP id 2qsdh7nwv3-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 20 Feb 2019 22:03:51 -0500 Received: from localhost by e12.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 21 Feb 2019 03:03:50 -0000 Received: from b01cxnp23032.gho.pok.ibm.com (9.57.198.27) by e12.ny.us.ibm.com (146.89.104.199) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Thu, 21 Feb 2019 03:03:49 -0000 Received: from b01ledav005.gho.pok.ibm.com (b01ledav005.gho.pok.ibm.com [9.57.199.110]) by b01cxnp23032.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x1L33mrK18874544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 21 Feb 2019 03:03:48 GMT Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3C488AE063; Thu, 21 Feb 2019 03:03:48 +0000 (GMT) Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F3C90AE05C; Thu, 21 Feb 2019 03:03:47 +0000 (GMT) Received: from otta.local (unknown [9.85.128.199]) by b01ledav005.gho.pok.ibm.com (Postfix) with ESMTP; Thu, 21 Feb 2019 03:03:47 +0000 (GMT) Subject: Re: Question regarding constraint usage within inline asm To: Alan Modra Cc: GCC References: <20190220030958.GC16787@bubble.grove.modra.org> <61bb9a58-0d4c-70e9-7611-3169de0c8950@linux.ibm.com> <20190220220437.GC23427@bubble.grove.modra.org> From: Peter Bergner Date: Thu, 21 Feb 2019 03:03:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190220220437.GC23427@bubble.grove.modra.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit x-cbid: 19022103-0060-0000-0000-0000030E7131 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00010635; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000281; SDB=6.01164060; UDB=6.00607851; IPR=6.00944645; MB=3.00025672; MTD=3.00000008; XFM=3.00000015; UTC=2019-02-21 03:03:49 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19022103-0061-0000-0000-0000485EADE2 Message-Id: <83bf56da-e673-1a3c-4383-2c646d7e122b@linux.ibm.com> X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00114.txt.bz2 On 2/20/19 4:04 PM, Alan Modra wrote: > On Wed, Feb 20, 2019 at 10:08:07AM -0600, Peter Bergner wrote: >> On 2/19/19 9:09 PM, Alan Modra wrote: >> That said, talking with Segher and Uli offline, they both think the >> inline asm usage in the test case should be legal > > Good, it seems we are in agreement. Incidentally, the single pseudo > for the inputs happens even for testcases like > > long input; > long > bug (void) > { > register long output /* asm ("r3") */; > asm ("blah %0, %1, %2" : "=r" (output) : "wi" (input), "0" (input)); > return output; > } This is a different problem than I'm fixing, but you are correct that asmcons shouldn't replace operand %1 since it has a non-compatible constraint than the output operand. In this case, it's probably "ok" to spill even though it's a hard register, because it doesn't match the regclass it is supposed to have. I'm not sure how important this is to fix. It can also imagine that this would be hard to handle, since we'd have to call into the backend to see whether the two constraints are compatible and with the overlap between different constraints, that could be very very messy! Peter