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 00DDA3846401 for ; Wed, 3 Apr 2024 09:02:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 00DDA3846401 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 00DDA3846401 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=1712134975; cv=none; b=Hi/67hiwbd+5GcRuf54C7R+iJV9/jp0L0cuu1VCbjtaWyWG0CgrmQUuxL/r3OMdovDhIu5CSHXnldQD4e+D8sOtSbwL2mTpnTGUH9DQVsaoBB3l4vkewqfn4fCG/aZztK+eiDSgaWrSQMzIz3gvtYXJa4GU1S9XrhQ+SsGthaiU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712134975; c=relaxed/simple; bh=rLl0/SJGfRKcku+t59T3ijPldyoDZcSsOzg1RMa3lTQ=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=A2UdDWSzrTGmyY40BolzgQwykPbAR1u7Wz1lZTAnQEi6yKMQRhcjIXEfqdJbSMkKC5dAV0vD353qO7MWoFRxcYZSj2c6JHqnwgJFQKYAI7XUwlnzFwF1o6bbt2s80AXmSBuP/66Wxp7MAgxq580Si/2aBnmQ+lEobIEUmsBrgoA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0353727.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 4338bXna004316; Wed, 3 Apr 2024 09:02:52 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=Lfgh9T7DG/OngAtn6ArgPXNkH6bmetmxh6AlzZkf2bA=; b=RrMSHFHgzo+4rl5bk2Qw5FikSIOXp+K2ygQ1EpZMvjRhZ+qpSTkH54NrYBhZERus+5qp ZZwrTEE0XyoN93gS9YzUNGPsgW/n2XJu/guiN7tXL/ZIqQFxmP6YN7YKF9jFxzCwWgKS 4FWTWqVwwYCmXtWXSc9nn4lTN6XOlgi2JmkNRnzDR6gcJF9PO/ZzgSbwQFShQjPBFM4e nVsTJtyIlc08JH5N3ZpdeIpNPUTnFcdT0sllD4Ut7satxOijzRFVdXx1/UjIEbIVrbIP jFawpsTJwAQVnaqwhOurIopHm1aVps0N/AlxYvVbbsM0DXWi2sGJWwKJNhPrOkn4WvwL ng== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3x93rt02h6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Apr 2024 09:02:52 +0000 Received: from m0353727.ppops.net (m0353727.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 43392pCg017634; Wed, 3 Apr 2024 09:02:51 GMT Received: from ppma12.dal12v.mail.ibm.com (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3x93rt02gx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Apr 2024 09:02:51 +0000 Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1]) by ppma12.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 4337UFGS008463; Wed, 3 Apr 2024 09:02:50 GMT Received: from smtprelay06.fra02v.mail.ibm.com ([9.218.2.230]) by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 3x6w2u4kq3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Apr 2024 09:02:50 +0000 Received: from smtpav03.fra02v.mail.ibm.com (smtpav03.fra02v.mail.ibm.com [10.20.54.102]) by smtprelay06.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 43392jT212190054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 3 Apr 2024 09:02:47 GMT Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6D0C020040; Wed, 3 Apr 2024 09:02:45 +0000 (GMT) Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A405220043; Wed, 3 Apr 2024 09:02:42 +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 09:02:42 +0000 (GMT) Message-ID: <5293fc93-5899-8863-e776-e2a75b0d97a4@linux.ibm.com> Date: Wed, 3 Apr 2024 17:02:40 +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: xoE3NUKARf4xTNc8d0oSO9zEwnXUP2uF X-Proofpoint-ORIG-GUID: RZEhN1NBYkdLDmotS-8CQBOIN0pA18_D 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_08,2024-04-01_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 lowpriorityscore=0 mlxlogscore=522 suspectscore=0 priorityscore=1501 impostorscore=0 malwarescore=0 clxscore=1015 spamscore=0 adultscore=0 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2403210000 definitions=main-2404030062 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/3 16:35, Jakub Jelinek wrote: > On Wed, Apr 03, 2024 at 01:18:54PM +0800, Kewen.Lin wrote: >>> 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)? > > I'd prefer not stripping them at all; they are clearly marked as perhaps not > passed in buggy programs (the DECL_HIDDEN_STRING_LENGTH argument) and > removing them implies the decl is a throw away, that after expansion Yes, IMHO it's safe as they are unused. > nothing will actually look at it anymore. I believe that is the case of > function bodies, we expand them into RTL and throw away the GIMPLE, and > after final clear the bodies, but it is not the case of the FUNCTION_DECL > or its DECL_ARGUMENTs etc. E.g. GIMPLE optimizations or expansion of > callers could be looking at those as well. At expand time GIMPLE optimizations should already finish, so it should be safe to strip them at that time? It would surprise me if expansions of callers will look at callee's information, it's more like what should be done in IPA analysis instead? > >> 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. > > The aim for the workaround was just avoid assuming there is a argument save > area in the caller stack when it is sometimes missing. Yeah, understood. > If you are looking for optimizations where nothing actually passes the > unneeded arguments and nothing expects them to be passed, then it is a task > for IPA optimizations and should be done solely if IPA determines that all > callers can be adjusted together with the callee; I think IPA already does > that in that case for years, regardless if it is DECL_HIDDEN_STRING_LENGTH > PARM_DECL or not. No, it's not what I was looking for. Peter's comments made me feel it's not good to have assembly at O0 like: std %r3,112(%r31) std %r4,120(%r31) std %r5,128(%r31) std %r6,136(%r31) std %r7,144(%r31) std %r8,152(%r31) std %r9,160(%r31) std %r10,168(%r31) std %r11,176(%r31) // this mislead people that we pass 9th arg via r11, // it would be nice not to have it. so I was thinking if there is some way to get rid of it. BR, Kewen