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 16BBB3858C36; Fri, 16 Jun 2023 02:24:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 16BBB3858C36 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 Received: from pps.filterd (m0353726.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 35G25vj6012990; Fri, 16 Jun 2023 02:24:49 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : references : date : in-reply-to : message-id : mime-version : content-type; s=pp1; bh=BFsRfP7zLJZRyB6sy+o/FRiT6dBmXFclEfzeYo8bnU4=; b=OBi4whWdmR5plo5TDCupPaGEtiow14Kd1brWzZ1u1TGEKOhuDRGecllOkilXCsrvj+w0 k3PGI+WkdGyf0ouCVf/7GywI24dWUgep/hepgwwUz6cub7Gb6Nv3TkUNbuUE5hmMXOaO 3C+Khf/q65a0nwU0zk8QsbiS4f2F8DTMvxD1w8sceNfoigt0cPOU36JhWWAtusOkemPw OpwCoFXsPa/+A/bS+Foiy4DCGI37EwWVueGP0qlNAN0hRshDxubKFUKPmXh+JhKt2iv9 VjIrzCqVd0kleU1auy4D1h7OqhxcMjlEQBV/yvj4oK1ERMaP0bAAkesLkGOcV2UZznlE Pw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3r8ec10qj2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Jun 2023 02:24:49 +0000 Received: from m0353726.ppops.net (m0353726.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 35G2LZnq031913; Fri, 16 Jun 2023 02:24:48 GMT Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3r8ec10qhs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Jun 2023 02:24:48 +0000 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 35FJYfWF030235; Fri, 16 Jun 2023 02:24:47 GMT Received: from smtprelay02.wdc07v.mail.ibm.com ([9.208.129.120]) by ppma03dal.us.ibm.com (PPS) with ESMTPS id 3r4gt51my5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Jun 2023 02:24:47 +0000 Received: from smtpav03.wdc07v.mail.ibm.com (smtpav03.wdc07v.mail.ibm.com [10.39.53.230]) by smtprelay02.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 35G2OkDu3080840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 16 Jun 2023 02:24:46 GMT Received: from smtpav03.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5BF7C5805A; Fri, 16 Jun 2023 02:24:46 +0000 (GMT) Received: from smtpav03.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DD89B58054; Fri, 16 Jun 2023 02:24:45 +0000 (GMT) Received: from ltcden2-lp1.aus.stglabs.ibm.com (unknown [9.3.90.43]) by smtpav03.wdc07v.mail.ibm.com (Postfix) with ESMTPS; Fri, 16 Jun 2023 02:24:45 +0000 (GMT) From: Jiufu Guo To: Segher Boessenkool Cc: gcc-patches@gcc.gnu.org, dje.gcc@gmail.com, linkw@gcc.gnu.org, bergner@linux.ibm.com, rguenther@suse.de, richard.sandiford@arm.com, jeffreyalaw@gmail.com Subject: Re: [PATCH] rs6000: replace '(const_int 0)' to 'unspec:BLK [(const_int 0)]' for stack_tie References: <20230613122335.2108620-1-guojiufu@linux.ibm.com> <20230613183320.GU19790@gate.crashing.org> <7no7liadru.fsf@ltcden2-lp1.aus.stglabs.ibm.com> <20230614151533.GW19790@gate.crashing.org> <7nwn058b1j.fsf@ltcden2-lp1.aus.stglabs.ibm.com> <20230615163023.GE19790@gate.crashing.org> Date: Fri, 16 Jun 2023 10:24:42 +0800 In-Reply-To: <20230615163023.GE19790@gate.crashing.org> (Segher Boessenkool's message of "Thu, 15 Jun 2023 11:30:24 -0500") Message-ID: <7nbkhg87px.fsf@ltcden2-lp1.aus.stglabs.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: kmf3Ppv16CmsE7RLKTAvSOHul2VttMZ- X-Proofpoint-GUID: 3HMW3EtJgzq4xT_QlznEzp2hp75hOlEL X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-06-15_17,2023-06-15_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 priorityscore=1501 bulkscore=0 spamscore=0 adultscore=0 malwarescore=0 lowpriorityscore=0 clxscore=1015 mlxlogscore=675 mlxscore=0 suspectscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2306160017 X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: Hi, Segher Boessenkool writes: > On Thu, Jun 15, 2023 at 03:00:40PM +0800, Jiufu Guo wrote: >> >> This is the existing pattern. It may be read as an action >> >> to clean an unknown-size memory block. >> > >> > Including a size zero memory block, yes. BLKmode was originally to do >> > things like bcopy (before modern names like memcpy were more usually >> > used), and those very much need size zero as well.h >> >> The size is possible to be zero. No asm code needs to >> be generated for "set 'const_int 0' to zero size memory"". >> stack_tie does not generate any real code. It seems ok :) >> >> While, it may not be zero size mem. This may be a concern. >> This is one reason that I would like to have an unspec_tie. > > It very much *can* be a zero size mem, that is perfectly find for > mem:BLK. There is still one concern: how to distinguish stack_tie from other insn. For example, below fake pattern: (define_insn "xx_cleanmem" [(parallel: [(set (mem:BLK (xxx)) (const_int 0)) (XXX/use "const_int_operand" "n")])]... To avoid this pattern to be recognized as 'stack_tie', 'unspec_tie' was came to mind. > >> Another reason is unspec:blk is used but various ports :) > > unspec:BLK is undefined. BLKmode is allowed on mem only. > >> >> 2. "set (mem/c:BLK (reg/f:DI 1 1) unspec:blk (const_int 0 [0]) >> >> UNSPEC_TIE". >> >> Current patch is using this one. >> > >> > What would be the semantics of that? Just the same as the current stuff >> > I'd say, or less? It cannot be more! >> >> The semantic that I trying to achieve is "this is a special >> insn, not only a normal set to unknown size mem". > > What does that *mean*? "Special instruction"? What would what code do > for that? What would the RTL mean? > >> As you explained before on 'unspec:DI', the unspec would >> just decorate the set_src part: something DI value with >> machine-specific operation. > > An unspec is an operation on its operands, giving some (in this case) > DImode value. There is nothing special about that operation, it can be > optimised like any other, it's just not specified what exactly that > value is (to the generic compiler, the backend itself can very much > optimise stuff with it). > >> But, since 'tie_operand' is checked for this insn. >> If 'tie_operand' checks UNPSEC_TIE, then the insn >> with UNPSEC_TIE is 'a special insn'. Or interpret >> the semantic of this insn as: this insn stack_ite >> indicates "set/operate a zero size block". > > tie_operand is a predicate. The predicate of an insn has to return 1, > or the insn is not recognised. You can do the same in insn conditions > always (in principle anyway). Thank you very much for your detailed and patient explanation! BR, Jeff (Jiufu Guo) > > > Segher