From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20768 invoked by alias); 18 Feb 2019 19:14:03 -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 18511 invoked by uid 89); 18 Feb 2019 19:13:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=lra, sees, truly, outright X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 18 Feb 2019 19:13:39 +0000 Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1IJ3xbW138042 for ; Mon, 18 Feb 2019 14:13:38 -0500 Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by mx0b-001b2d01.pphosted.com with ESMTP id 2qr1tyag07-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 18 Feb 2019 14:13:38 -0500 Received: from localhost by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 18 Feb 2019 19:13:37 -0000 Received: from b03cxnp08026.gho.boulder.ibm.com (9.17.130.18) by e33.co.us.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Mon, 18 Feb 2019 19:13:34 -0000 Received: from b03ledav002.gho.boulder.ibm.com (b03ledav002.gho.boulder.ibm.com [9.17.130.233]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x1IJDWUc15990840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 18 Feb 2019 19:13:32 GMT Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 77A4D13604F; Mon, 18 Feb 2019 19:13:32 +0000 (GMT) Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 03A17136053; Mon, 18 Feb 2019 19:13:31 +0000 (GMT) Received: from otta.local (unknown [9.80.227.110]) by b03ledav002.gho.boulder.ibm.com (Postfix) with ESMTP; Mon, 18 Feb 2019 19:13:31 +0000 (GMT) To: GCC From: Peter Bergner Subject: Question regarding constraint usage within inline asm Date: Mon, 18 Feb 2019 19:14:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit x-cbid: 19021819-0036-0000-0000-00000A8E084A X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00010621; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000281; SDB=6.01162956; UDB=6.00607184; IPR=6.00943532; MB=3.00025641; MTD=3.00000008; XFM=3.00000015; UTC=2019-02-18 19:13:35 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19021819-0037-0000-0000-00004AC5FFFE Message-Id: X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00093.txt.bz2 I have a question about constraint usage in inline asm when we have an early clobber output operand. The test case is from PR89313 and looks like the code below (I'm using "r3" for the reg on ppc, but you could also use "rax" on x86_64, etc.). long input; long bug (void) { register long output asm ("r3"); asm ("blah %0, %1, %2" : "=&r" (output) : "r" (input), "0" (input)); return output; } I know an input operand can have a matching constraint associated with an early clobber operand, as there seems to be code that explicitly mentions this scenario. In this case, the user has to manually ensure that the input operand is not clobbered by the early clobber operand. In the case that the input operand uses an "r" constraint, we just ensure that the early clobber operand and the input operand are assigned different registers. My question is, what about the case above where we have the same variable being used for two different inputs with constraints that seem to be incompatible? Clearly, we cannot assign a register to the "input" variable that is both the same and different to the register that is assigned to "output". Is this outright invalid to have "input" use both a matching and non-matching constraint with an early clobber operand? Or is is expected that reload/LRA will come along and fix up the "r" usage to use a different register? My guess is that this is invalid usage and I have a patch to expand_asm_stmt() to catch this, but it only works if we've preassigned "output" to a hard register. If this is truly invalid, should I flag this even if "output" isn't preassigned? If it is valid, then should match_asm_constraints_1() really rewrite all of the uses of "input" with the register assigned to output as it is doing now, which is what is causing the problems in LRA. LRA sees that both input operands are using r3 and it catches the constraint violation of the "r" input and tries to spill it, but it's not a pseudo, but an explicit hard register already. I'm not sure LRA can really safely spill an operand that is an explicit hard register. Thoughts? Peter