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 556A53858D28 for ; Sat, 23 Mar 2024 16:03:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 556A53858D28 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 556A53858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.158.5 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711209816; cv=none; b=jb3iFVRjFwcj4kcbsWu8IYJYXv3nOLzO4MSFtuBv8odn8SGkKCEXYTkBPGuKN4ps1zpFjqNBivDLrc4GdigXkJYi3zlOHGZbJvsKGlBAN3O+R/BAox+Y8NCAYXznn3tsiQIubRN69oW5mcGd0VsW47irC6tTflFNCWqfDibIeDU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711209816; c=relaxed/simple; bh=0ANuI2bVG/GvRVMnTGujn2LtWh/Yo32nIm8yOlivO1o=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=IB87VSU0t7lho9kRwluPVuNbowhLugOmLPjdmbRsZ7+mzdpPxKMwOT9HXLTEaCoZDKmFu7LMSel2KGB9QORVIhd1fXlCVAJHJa+vu3Psxf/bFcgVd3M9+oVxo6Hh8n4ITcs8xbCdLMGAw8wT8zoP2P7YR9mqmivgLxkyJfZoIcM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0353724.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 42NFxVuV031618; Sat, 23 Mar 2024 16:03:26 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=2EXtYuhJlliQkFmhfGk8bvfL4vx/OrW9bDuMXYk3mUI=; b=g7yFm2MgjC3cbBHqxXgD6JH86dQeMO1l+h+y7vGbTE0iyRMCG/Zr1fgNdzWQiFNpfa3X HZEFiIUw2hoseWCqYBVD9J44r0YLh8LQ5jxRofDtMrvBXtJNG52ViihFqBlQUpIPppkG UhMQyMTGYAKh18m31YF1xxpJKYrXuQ+tyb16YHs01Y5FqCCXCOYyz9L3VQQ8rASfsMuL M5J8wsi6Ufkv6P3Nvy11D0Wvt9x+kscZXjKFAGMgy3BuvbFwH1LRNjT46FUw/48sXLCE bnGnNGmqKrK4+lrBzlntLNXm6PQpNFsnHSr7m2MO7iJoVJGN3dGD6u+IP5N2nBmmovD7 ow== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3x226kr0dd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 23 Mar 2024 16:03:25 +0000 Received: from m0353724.ppops.net (m0353724.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 42NG3PHL005862; Sat, 23 Mar 2024 16:03:25 GMT Received: from ppma11.dal12v.mail.ibm.com (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3x226kr0da-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 23 Mar 2024 16:03:24 +0000 Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1]) by ppma11.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 42NDUQK0015696; Sat, 23 Mar 2024 16:03:24 GMT Received: from smtprelay06.dal12v.mail.ibm.com ([172.16.1.8]) by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 3x0x15vyn5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 23 Mar 2024 16:03:24 +0000 Received: from smtpav01.wdc07v.mail.ibm.com (smtpav01.wdc07v.mail.ibm.com [10.39.53.228]) by smtprelay06.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 42NG3LhK61145490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 23 Mar 2024 16:03:23 GMT Received: from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3434C5806B; Sat, 23 Mar 2024 16:03:21 +0000 (GMT) Received: from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5CFF05805B; Sat, 23 Mar 2024 16:03:20 +0000 (GMT) Received: from [9.61.153.201] (unknown [9.61.153.201]) by smtpav01.wdc07v.mail.ibm.com (Postfix) with ESMTP; Sat, 23 Mar 2024 16:03:20 +0000 (GMT) Message-ID: <6a592b9f-d536-4a0e-aa00-ee8d4a778afc@linux.ibm.com> Date: Sat, 23 Mar 2024 11:03:19 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] rs6000: Stackoverflow in optimized code on PPC [PR100799] Content-Language: en-US To: Ajit Agarwal , Jakub Jelinek , "Kewen.Lin" , 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> From: Peter Bergner In-Reply-To: <76307976-77b0-48f0-90b9-6dcec02e3c8f@linux.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: OlD80z28fpqK5XQYSxsStQCrTwcZl13y X-Proofpoint-GUID: 4FpgSP1XZ0htEtD5YT8Y6bLvmU6U_8wM 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-03-23_10,2024-03-21_02,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 priorityscore=1501 impostorscore=0 clxscore=1015 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 lowpriorityscore=0 malwarescore=0 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2403210000 definitions=main-2403230108 X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,KAM_MANYTO,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 3/23/24 4:33 AM, Ajit Agarwal wrote: >>> - else if (align_words < GP_ARG_NUM_REG) >>> + else if (align_words < GP_ARG_NUM_REG >>> + || (cum->hidden_string_length >>> + && cum->actual_parm_length <= GP_ARG_NUM_REG)) >> { >> if (TARGET_32BIT && TARGET_POWERPC64) >> return rs6000_mixed_function_arg (mode, type, align_words); >> >> return gen_rtx_REG (mode, GP_ARG_MIN_REG + align_words); >> } >> else >> return NULL_RTX; >> >> 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 >> unused hidden parameter and we return r12 and r13 which have specific uses >> in our ABIs (eg, r13 is our TCB pointer), so it may not actually look dead. >> Have you verified what the callee RTL looks like after expand for these >> unused hidden parameters? Is there a rtx we can return that isn't a NULL_RTX >> which triggers the assumption of a parameter save area, but isn't a reg rtx >> which might lead to some rtl being generated? Would a (const_int 0) or >> something else work? >> >> > For the above use case it will return > > (reg:DI 5 %r5) and below check entry_parm = > (reg:DI 5 %r5) and the following check will not return TRUE and hence > parameter save area will not be allocated. Why r5?!?! The 8th (integer) param would return r10, so I'd assume if the next param was a hidden param, then it'd get the next gpr, so r11. How does it jump back to r5 which may have been used by the 3rd param? > It will not generate any rtx in the callee rtl code but it just used to > check whether to allocate parameter save area or not when number of args > 8. > > /* If there is no incoming register, we need a stack. */ > entry_parm = rs6000_function_arg (args_so_far, arg); > if (entry_parm == NULL) > return true; > > /* Likewise if we need to pass both in registers and on the stack. */ > if (GET_CODE (entry_parm) == PARALLEL > && XEXP (XVECEXP (entry_parm, 0, 0), 0) == NULL_RTX) > return true; Yes, this code in rs6000_parm_needs_stack() uses the rs6000_function_arg() return value as a boolean to tell us whether a parameter save area is required so what we return is unimportant other than to know it's not NULL_RTX. I'm more concerned about the use of the target hook targetm.calls.function_arg used in the generic parts of the compiler. What will that code do differently now that we return a reg rtx rather than NULL_RTX? Might that code use the reg rtx to emit something? I'd feel better if you could verify what happens in that code when we return a reg rtx for that 9th hidden param which isn't really being passed in a register. Peter