From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 16D7D3858D38; Wed, 14 Jun 2023 09:27:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 16D7D3858D38 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 (m0360072.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 35E9KFV7022165; Wed, 14 Jun 2023 09:27:03 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=jffcEw5cNqHjs0EYdSQcqJoGkrkLwKWNv3Yexw4VlgQ=; b=IMWqs0D819rEM7uWMIbinsuVdAP3E0E1nybGJjgD+1Skt571s5BkDdramnEMdTtrbkUt l0/POJSAd/PhbdzwsiDMi8Bd4BdXrg5dn9nDraVmag9181w76XFU+gJwB1ByoSzdvKqi LRykHZ9tqdGzEfKlVQT50RcnLSF1a4pmrLMbEaCg0aZ5NrpXuRlXFkpVRRY83Y9kggTa 4d0rikf4ewYrqD/iEeGTwTcFvhQRHafG6Jz4Ft5tZXuEGXcfPwkFkWV4FhLLscjFEelt R855/sat7Bv5x0eISjugnbuYTaKWwSRKh5uDNjUzty/b0TmfJglv8ryOK2Go4SQn1blI 2A== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3r7attr4yx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jun 2023 09:27:02 +0000 Received: from m0360072.ppops.net (m0360072.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 35E9P4Rq006659; Wed, 14 Jun 2023 09:27:02 GMT Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3r7attr4yn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jun 2023 09:27:02 +0000 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 35E74MCu012048; Wed, 14 Jun 2023 09:27:01 GMT Received: from smtprelay06.wdc07v.mail.ibm.com ([9.208.129.118]) by ppma01dal.us.ibm.com (PPS) with ESMTPS id 3r4gt68p0t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jun 2023 09:27:01 +0000 Received: from smtpav04.dal12v.mail.ibm.com (smtpav04.dal12v.mail.ibm.com [10.241.53.103]) by smtprelay06.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 35E9QxBr61800742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 Jun 2023 09:27:00 GMT Received: from smtpav04.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B22365805A; Wed, 14 Jun 2023 09:26:59 +0000 (GMT) Received: from smtpav04.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 841CE58052; Wed, 14 Jun 2023 09:26:59 +0000 (GMT) Received: from ltcden2-lp1.aus.stglabs.ibm.com (unknown [9.3.90.43]) by smtpav04.dal12v.mail.ibm.com (Postfix) with ESMTPS; Wed, 14 Jun 2023 09:26:59 +0000 (GMT) From: Jiufu Guo To: Richard Biener Cc: Segher Boessenkool , gcc-patches@gcc.gnu.org, dje.gcc@gmail.com, linkw@gcc.gnu.org, bergner@linux.ibm.com, 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> Date: Wed, 14 Jun 2023 17:26:52 +0800 In-Reply-To: (Richard Biener's message of "Wed, 14 Jun 2023 07:59:04 +0000 (UTC)") Message-ID: <7nilbq9yxv.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-GUID: 6IxLbjWueY98pq3-f7_eCCSsWfFXAw5B X-Proofpoint-ORIG-GUID: Z7y0LPqResgta5-oTFfQYdR50VzR8Tl7 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-14_06,2023-06-12_02,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 mlxlogscore=964 mlxscore=0 malwarescore=0 priorityscore=1501 bulkscore=0 clxscore=1015 phishscore=0 adultscore=0 spamscore=0 suspectscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2306140076 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, Richard Biener writes: > On Wed, 14 Jun 2023, Jiufu Guo wrote: > >> >> Hi, >> >> Segher Boessenkool writes: >> >> > Hi! >> > >> > As I said in a reply to the original patch: not okay. Sorry. >> >> Thanks a lot for your comments! >> 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. >> >> 2. "set (mem/c:BLK (reg/f:DI 1 1) unspec:blk (const_int 0 [0]) >> UNSPEC_TIE". >> Current patch is using this one. >> >> 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. > > That gives the MEM a size which means we can interpret the (set ..) > as killing a specific area of memory, enabling DSE of earlier > stores. Oh, thanks! While with 'unspec:DI', I'm wondering if it means this 'set' would do some special things other than pure 'set' to the memory. BR, Jeff (Jiufu Guo) > > AFAIU this special instruction is only supposed to prevent > code motion (of stack memory accesses?) across this instruction? > I'd say a > > (may_clobber (mem:BLK (reg:DI 1 1))) > > might be more to the point? I've used "may_clobber" which doesn't > exist since I'm not sure whether a clobber is considered a kill. > The docs say "Represents the storing or possible storing of an > unpredictable..." - what is it? Storing or possible storing? > I suppose stack_tie should be less strict than the documented > (clobber (mem:BLK (const_int 0))) (clobber all memory). > > ? > >> 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. >> >> >> > >> > But some comments on this patch: >> > >> > 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);". >> >> > >> >> + RTVEC_ELT (p, i) >> >> + = gen_rtx_SET (mem, gen_rtx_UNSPEC (BLKmode, gen_rtvec (1, const0_rtx), >> >> + UNSPEC_TIE)); >> > >> > If it is hard to indent your code, your code is trying to do to much. >> > Just have an extra temporary? >> > >> > rtx un = gen_rtx_UNSPEC (BLKmode, gen_rtvec (1, const0_rtx), UNSPEC_TIE); >> > RTVEC_ELT (p, i) = gen_rtx_SET (mem, un); >> > >> > That is shorter even, and certainly more readable :-) >> >> Yeap, thanks! >> >> > >> >> @@ -10828,7 +10829,9 @@ (define_expand "restore_stack_block" >> >> operands[4] = gen_frame_mem (Pmode, operands[1]); >> >> p = rtvec_alloc (1); >> >> RTVEC_ELT (p, 0) = gen_rtx_SET (gen_frame_mem (BLKmode, operands[0]), >> >> - const0_rtx); >> >> + gen_rtx_UNSPEC (BLKmode, >> >> + gen_rtvec (1, const0_rtx), >> >> + UNSPEC_TIE)); >> >> operands[5] = gen_rtx_PARALLEL (VOIDmode, p); >> > >> > I have a hard time to see how this could ever be seen as clearer or more >> > obvious or anything like that :-( >> >> I was thinking about just invoking gen_stack_tie here. >> >> BR, >> Jeff (Jiufu Guo) >> >> > >> > >> > Segher >>