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 B987E3858CDA for ; Wed, 3 Apr 2024 05:19:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B987E3858CDA 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 B987E3858CDA 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=1712121549; cv=none; b=hJr8uWv+hoz/SxLXpgcmgMyiE6Okj4Ysuj8g3522AAfMNOXjTTWvgxHBHP+Oz//jTtGLgx6sZy8huP4j/XPFw4gFuedG/0rVJziordYywtRIrNBr5/yHCSr85zVIOW8j9F0Q/Bs83tznQ5VJ5baw8mrgYXPP2Ftl/OqpyJiVEBE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712121549; c=relaxed/simple; bh=Run4rFy0fh6oehoLKOG7ykd3dMwMnHIwAlcBcJ77NZk=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=V8u0pPeb/b4kBrvOYOvIGzTFmmUtKhTld/4IC2scjI5EynWlrz6KCpdmPRWqlE+5H/L4YSqUwPvq4TnO7wLAI2Al0oXrtB0tF5jNSTe8wFBGqPhTjEgCosVPGXQxVTR39LrjKa8sONXty+eFSI4+QSLReBIEl3V24mSTV129dZc= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0360083.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 4335BVUP012747; Wed, 3 Apr 2024 05:19:06 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=clqnDl5QW8Z67CWJ9XOxL/qbkDdEfBo2aIONeRiaoYs=; b=VKB5nISeZ8kULcM0OaJkZS7alrYcNkNFFVkRn2ceKSJYB1gWSs15BomhyWnfuHS5vuYw XaT/AsGSO6/JpDdJYvDYfu0U2Ii8/bPnf1kyeivzxfjRaoAC5fpRlg/5cdFCob1T4+UO y4xybr7vKqQLH0yW/E57WmdITMJZKCFgICJQyTb8aL31Urvj6gBg+7t5g8A7iu5RhHm6 I4OZdmPs+VG7dobnNI+Ut0Wj+cKJzHAAh8NMB0gpqTNpiFmiushaMWVyMjJ2Boz4LbAI qTySU6sU1OMxW0+QJ4Gp2mzFT6tyuGkx3EhZhFcPbbiZ9tw3GpCrLiDE6HzTuda4OITB Dg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3x905983bf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Apr 2024 05:19:06 +0000 Received: from m0360083.ppops.net (m0360083.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 4335J5ia027618; Wed, 3 Apr 2024 05:19:05 GMT 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 3x905983bb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Apr 2024 05:19:05 +0000 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 4332oBfr002184; Wed, 3 Apr 2024 05:19:04 GMT Received: from smtprelay05.fra02v.mail.ibm.com ([9.218.2.225]) by ppma23.wdc07v.mail.ibm.com (PPS) with ESMTPS id 3x6xjmk453-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Apr 2024 05:19:04 +0000 Received: from smtpav03.fra02v.mail.ibm.com (smtpav03.fra02v.mail.ibm.com [10.20.54.102]) by smtprelay05.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 4335IwJN43581740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 3 Apr 2024 05:19:00 GMT Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8A2FC20043; Wed, 3 Apr 2024 05:18:58 +0000 (GMT) Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 18CE120040; Wed, 3 Apr 2024 05:18:56 +0000 (GMT) Received: from [9.200.57.240] (unknown [9.200.57.240]) by smtpav03.fra02v.mail.ibm.com (Postfix) with ESMTP; Wed, 3 Apr 2024 05:18:55 +0000 (GMT) Message-ID: Date: Wed, 3 Apr 2024 13:18:54 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH v2] rs6000: Stackoverflow in optimized code on PPC [PR100799] Content-Language: en-US To: Jakub Jelinek Cc: Ajit Agarwal , Peter Bergner , Segher Boessenkool , David Edelsohn , Michael Meissner , gcc-patches References: <8e8dad73-43a6-4764-a496-b600e6a220e1@linux.ibm.com> <76307976-77b0-48f0-90b9-6dcec02e3c8f@linux.ibm.com> <6a592b9f-d536-4a0e-aa00-ee8d4a778afc@linux.ibm.com> <5a2e511a-3a29-4cdd-88b1-12a6274d5a79@linux.ibm.com> From: "Kewen.Lin" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: l4m-idgE5v9r06zmGKAkRA2g20iSsMZ8 X-Proofpoint-ORIG-GUID: L-ttjImomGBDKyt3sa1qS0Y-eJVMMhuV X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-04-03_04,2024-04-01_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=703 malwarescore=0 adultscore=0 priorityscore=1501 lowpriorityscore=0 mlxscore=0 impostorscore=0 spamscore=0 bulkscore=0 suspectscore=0 phishscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2403210000 definitions=main-2404030033 X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_MSPIKE_H4,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: Hi Jakub, on 2024/4/2 16:03, Jakub Jelinek wrote: > On Tue, Apr 02, 2024 at 02:12:04PM +0800, Kewen.Lin wrote: >>>>>> The old code for the unused hidden parameter (which was the 9th param) would >>>>>> fall thru to the "return NULL_RTX;" which would make the callee assume there >>>>>> was a parameter save area allocated. Now instead, we'll return a reg rtx, >>>>>> probably of r11 (r3 thru r10 are our param regs) and I'm guessing we'll now >>>>>> see a copy of r11 into a pseudo like we do for the other param regs. >>>>>> Is that a problem? Given it's an unused parameter, it'll probably get deleted >>>>>> as dead code, but could it cause any issues? What if we have more than one >> >> I think Peter raised one good point, not sure it would really cause some issues, >> but the assigned reg goes beyond GP_ARG_MAX_REG, at least it is confusing to people >> especially without DCE like at -O0. Can we aggressively remove these candidates >> from DECL_ARGUMENTS chain? Does it cause any assertion to fail? > > I'd prefer not to remove DECL_ARGUMENTS chains, they are valid arguments that just some > invalid code doesn't pass. By removing them you basically always create an > invalid case, this time in the other direction, valid caller passes more > arguments than the callee (invalidly) expects. Thanks for the comments, do you mean it can affect the arguments validation when there is explicit function declaration with interface? Then can we strip them when we are going to expand them (like checking currently_expanding_function_start)? since from the perspective of resulted assembly, with this workaround, the callee can: 1) pass the hidden args in unexpected GPR like r11, ... at -O0; 2) get rid of such hidden args as they are unused at -O2; This proposal aims to make the assembly at -O0 not to pass with r11... (same as -O2), comparing to the assembly at O2, the mismatch isn't actually changed. BR, Kewen