From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 9AF62382FAD9 for ; Sat, 22 Jun 2024 14:08:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9AF62382FAD9 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 9AF62382FAD9 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.156.1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719065288; cv=none; b=nYFISaYu/7XUVrdzXxn0lMxguz9dnKlegs8NglkcH+LlGGeeke1fkMZ9b/XiWQ3yrwVEqCEoX263t9Uyz2YpF24WuREMjsd4mQqh16tLctMHm5ToTgtV1SDCNJY22TIuqbqaJd+IDafnhKwu2a1z2b3GMpUNdDZA9gaG5GRkLiA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719065288; c=relaxed/simple; bh=p5dy2Ng4V2Q4Yb7H5NJHEbmoXFHNdFN5Y1P3giq2Uj4=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=O5ZT91VAnN6DPv1pUtHAMqGi7ym38Ks7WlqFvulmFDRv9ncaultEBQcD7NgJMGdnRRXJmuFrFTLn/JAdkboO9omTbQhexCxODvctZpIkld9QKzCdotzSWiPl4GEDhj2vKJTOh/iySzJ/gYdfUUFbckAgFkp0b/mUQhVpKqKvvVQ= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0353726.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 45M8QhRL019047; Sat, 22 Jun 2024 08:46:26 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=pp1; bh=QljzAAUsceejFXQbYBI/WFepnfP aA2WqV2hOaAl3aUk=; b=qyRmgo5AjOQXTN8KlQF77HvbslhE36d4xFZ/XqH7+0r oC3qw34Q6pTneP4RN3+QzViW8ol8NRiFgTcifR6xAvqymcx8gSfdrO0OVwTJ4lKM nXtq1Po6lhsKztWZfcdyugFAdxyQ3rQIZDkH4IPT3Lbs4bv4gBGJxT9exDr4Gh7U L/MMeOmaWsP0BG0mBz0uDNnH+GjghSB30ZASHWJaANm3ArtC6p5WTwdnmDZZH0sl yeEyNic4Mr6lRvdq+mxey6Mu6yx+ibXxj2QcIHQT4XgoZB5zzMiCWIiiZaS8+xRw ZavCM8rCdxuCItkZyyzzoVQLe1HUGtRlopHFbS6U+qg== Received: from ppma23.wdc07v.mail.ibm.com (5d.69.3da9.ip4.static.sl-reverse.com [169.61.105.93]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3ywspeg61p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 22 Jun 2024 08:46:26 +0000 (GMT) Received: from pps.filterd (ppma23.wdc07v.mail.ibm.com [127.0.0.1]) by ppma23.wdc07v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 45M7aGhq031351; Sat, 22 Jun 2024 08:46:25 GMT Received: from smtprelay04.fra02v.mail.ibm.com ([9.218.2.228]) by ppma23.wdc07v.mail.ibm.com (PPS) with ESMTPS id 3yvrrqbms4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 22 Jun 2024 08:46:25 +0000 Received: from smtpav05.fra02v.mail.ibm.com (smtpav05.fra02v.mail.ibm.com [10.20.54.104]) by smtprelay04.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 45M8kLsU19661194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 22 Jun 2024 08:46:23 GMT Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1FE2D2004B; Sat, 22 Jun 2024 08:46:21 +0000 (GMT) Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E389120040; Sat, 22 Jun 2024 08:46:20 +0000 (GMT) Received: from li-819a89cc-2401-11b2-a85c-cca1ce6aa768.ibm.com (unknown [9.171.19.43]) by smtpav05.fra02v.mail.ibm.com (Postfix) with ESMTPS; Sat, 22 Jun 2024 08:46:20 +0000 (GMT) Date: Sat, 22 Jun 2024 10:46:20 +0200 From: Stefan Schulze Frielinghaus To: Georg-Johann Lay Cc: gcc@gcc.gnu.org Subject: Re: Setting insn mnemonic partly automagically Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: CSHZhIfkJxpP6X_BybToj7nvXHI_vz1p X-Proofpoint-GUID: CSHZhIfkJxpP6X_BybToj7nvXHI_vz1p 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-22_04,2024-06-21_01,2024-05-17_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 lowpriorityscore=0 phishscore=0 suspectscore=0 mlxlogscore=999 priorityscore=1501 clxscore=1011 impostorscore=0 spamscore=0 adultscore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2406140001 definitions=main-2406220056 X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,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 21, 2024 at 09:50:43PM +0200, Georg-Johann Lay wrote: > > > Am 17.06.24 um 21:13 schrieb Stefan Schulze Frielinghaus via Gcc: > > Hi all, > > > > I'm trying to add an alternative to an existing insn foobar: > > > > (define_insn "foobar" > > [(set (match_operand ...) > > (match_operand ...))] > > "" > > "@ > > foo > > bar > > #") > > > > Since the asm output depends on the operands in a non-trivial way which isn't > > easily solved via iterators, I went for a general C function and came up with: > > > > (define_insn "foobar" > > [(set (match_operand ...) > > (match_operand ...))] > > "" > > "@ > > foo > > * return foobar_helper (operands[0], operands[1]); > > bar > > #" > > [(set_attr_alternative "mnemonic" [(const_string "foo") > > (const_string "specialcase") > > (const_string "bar") > > (const_string "unknown")])]) > > > > If there exist a lot of alternatives, then setting the mnemonic attribute like > > this feels repetitive and is error prone. Furthermore, if there exists no > > other insn with an output template containing foo/bar, then I would have to > > declare foo/bar via > > > > (define_attr "mnemonic" "...,foo,bar,..." (const_string "unknown")) > > > > which again is repetitive. Thus, I'm wondering if there exists a more elegant > > way to achieve this? Ultimately, I would like to set the mnemonic > > attribute only manually for the alternative which is implemented via C > > code and let the mnemonic attribute for the remaining alternatives be > > set automagically. Not sure whether this is supported? > > > > If all fails, I have another idea how to solve this by utilizing PRINT_OPERAND. > > However, now I'm curious whether my current attempt is feasible or not. > > > > Cheers, > > Stefan > > It's a bit unclear to me what you are trying to do, as you are not only > adding an insn alternative, but also are adding insn attribute > "mnemonic", which the original insn did not have. My take so far is that every insn has a mnemonic attribute which is set either explicitly or implicitly (assuming that the target requested this via define_attr "mnemonic" "..."). This is done in function gen_mnemonic_attr() from gensupport.cc. Thus, something like (define_insn "foobar" [(set (match_operand ...) (match_operand ...))] "" "@ foo bar #") and (define_insn "foobar" [(set (match_operand ...) (match_operand ...))] "" "@ foo bar #" [(set_attr_alternative "mnemonic" [(const_string "foo") (const_string "bar") (const_string "unknown")])]) should be equivalent. Of course, the implicit method fails if the pattern is generated via C statements which is way I set it manually in the initial example. The initial example contained 3 alternatives plus 1 for the generated one. Setting it manually there might be feasible, however, for my actual problem I have an insn with 27 alternatives where I do not want to set and maintain it manually. A side effect of setting the attribute implicitly is that each mnemonic is added automatically to the mnemonic hash table which I would have to do manually for my 27 alternatives which I would like to avoid, too. > > Also, it's unclear how PRINT_OPERAND would help with setting the attribute. For my particular problem I think one can also utilize PRINT_OPERAND which I should have elaborated a bit more but feared to make the example unnecessarily complicated. The C code foobar_helper (operands[0], operands[1]) emits actually an extended mnemonic "specialcase$VAR\t%0,%1" where $VAR can be either A, B, or C. The extended mnemonic is just syntactic sugar for the base mnemonic "specialcase\t%0,%1,$IMM" which is why we can lie and hard code the mnemonic attribute to specialcase since this won't effect scheduling. Since the choice which extended mnemonic should be used depends only on operands[1] I thought about rewriting all this into (define_insn "foobar" [(set (match_operand ...) (match_operand ...))] "" "@ foo specialcase\t%0,%1,%X1 bar #") Obviously we have to sacrifice the usage of an extended mnemonic but more problematic is that we have to allocate one of those very few codes X just for this insn. So this doesn't scale either if one has to come up with many different codes. Furthermore, this only works in my very particular case since I can split the extended mnemonic into a base mnemonic and an immediate which only depends on one operand, i.e., it would fail if it depended on operands[0] and operands[1]. I hope this makes it a bit more clear, if not just let me know. Cheers, Stefan > > Johann