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 B917B3858C2F; Thu, 15 Jun 2023 07:00:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B917B3858C2F 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 (m0356517.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 35F6leaI019761; Thu, 15 Jun 2023 07:00:46 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=9K8zf/xvpuDM5QHU/XLX/rmuuP4ULLVzIOBcM1BhMzc=; b=El0BDZiLSx28NZtHzHL0J94m0OiEhO2oqX9iJemhspbUa+/IZnIJJuF0c0qj6zPJcHVc 3i5tbpXo1c/sEv2gU6F/puNEZ6InE/c0zhwVZf8ikbRcPYEAXcVXCNoKmigjIz1k9s0I 84EflcibbrEVdWzFn54qgVetqMjTDdX4jHaGDj8BUNlqSBDiywlyW5LWBc/H8NmpKHGK yL2xxlb7eHyUC7c7xkKSYTrlysi69z4rfcPLJg2Q7A8ANc5KaU1dR44Blzv4cFvKxQM2 5exyIyi0bCxj15KnUq6Qy6o1OvJ6vYXX+MXMLAdQQuGA9PsQtM5PmCdfBxrjwp96oBLy hw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3r7wpbr9ay-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Jun 2023 07:00:46 +0000 Received: from m0356517.ppops.net (m0356517.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 35F6mLKq020844; Thu, 15 Jun 2023 07:00:45 GMT Received: from ppma02dal.us.ibm.com (a.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.10]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3r7wpbr9aa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Jun 2023 07:00:45 +0000 Received: from pps.filterd (ppma02dal.us.ibm.com [127.0.0.1]) by ppma02dal.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 35F6Fm9R027273; Thu, 15 Jun 2023 07:00:44 GMT Received: from smtprelay02.wdc07v.mail.ibm.com ([9.208.129.120]) by ppma02dal.us.ibm.com (PPS) with ESMTPS id 3r4gt67tgv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Jun 2023 07:00:44 +0000 Received: from smtpav02.dal12v.mail.ibm.com (smtpav02.dal12v.mail.ibm.com [10.241.53.101]) by smtprelay02.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 35F70gEP60621140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 15 Jun 2023 07:00:42 GMT Received: from smtpav02.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7B4AC5805C; Thu, 15 Jun 2023 07:00:42 +0000 (GMT) Received: from smtpav02.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 54F7758051; Thu, 15 Jun 2023 07:00:42 +0000 (GMT) Received: from ltcden2-lp1.aus.stglabs.ibm.com (unknown [9.3.90.43]) by smtpav02.dal12v.mail.ibm.com (Postfix) with ESMTPS; Thu, 15 Jun 2023 07:00:42 +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> Date: Thu, 15 Jun 2023 15:00:40 +0800 In-Reply-To: <20230614151533.GW19790@gate.crashing.org> (Segher Boessenkool's message of "Wed, 14 Jun 2023 10:15:33 -0500") Message-ID: <7nwn058b1j.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: Oa_oZaj59wwlbDEcIuzO0CXeCLnimDYx X-Proofpoint-GUID: dFm1OWr_AGPD1503NQajI40l-aJb_wLw X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.573,FMLib:17.11.176.26 definitions=2023-06-15_03,2023-06-14_02,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 mlxlogscore=918 lowpriorityscore=0 mlxscore=0 bulkscore=0 priorityscore=1501 adultscore=0 phishscore=0 malwarescore=0 impostorscore=0 clxscore=1015 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2306150054 X-Spam-Status: No, score=-5.0 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: > Hi! > > On Wed, Jun 14, 2023 at 12:06:29PM +0800, Jiufu Guo wrote: >> Segher Boessenkool writes: >> I'm also thinking about other solutions: >> 1. "set (mem/c:BLK (reg/f:DI 1 1) (const_int 0 [0])" >> 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. Another reason is unspec:blk is used but various ports :) > >> 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". As you explained before on 'unspec:DI', the unspec would just decorate the set_src part: something DI value with machine-specific operation. 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". Does this make sense? > >> 3. "set (mem/c:DI (reg/f:DI 1 1) unspec:DI (const_int 0 [0]) >> UNSPEC_TIE". >> This avoids using BLK on unspec, but using DI. > > And is incorrect because of that. > >> 4. "set (mem/c:BLK (reg/f:DI 1 1) unspec (const_int 0 [0]) >> UNSPEC_TIE" >> There is still a mode for the unspec. > > It has VOIDmode here, which is incorrect. > >> > On Tue, Jun 13, 2023 at 08:23:35PM +0800, Jiufu Guo wrote: >> >> + && XINT (SET_SRC (set), 1) == UNSPEC_TIE >> >> + && XVECEXP (SET_SRC (set), 0, 0) == const0_rtx); >> > >> > This makes it required that the operand of an UNSPEC_TIE unspec is a >> > const_int 0. This should be documented somewhere. Ideally you would >> > want no operand at all here, but every unspec has an operand. >> >> Right! Since checked UNSPEC_TIE arleady, we may not need to check >> the inner operand. Like " && XINT (SET_SRC (set), 1) == UNSPEC_TIE);". > > Yes. But we should write down somewhere (in a comment near the unspec > constant def for example) what the operand is -- so, "operand is usually > (const_int 0) because we have to put *something* there" or such. The > clumsiness of this is enough for me to prefer some other solution > already ;-) Thanks a lot for your comments! BR, Jeff (Jiufu Guo) > > > Segher