From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id D18FA3952517; Tue, 6 Dec 2022 02:36:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D18FA3952517 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 (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2B5NX9Mm028475; Tue, 6 Dec 2022 02:36:58 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=vOipywmOqovnC+8wZIaLVlG1pRKMfXzLjOwtoiHBvBc=; b=YIV6TXKvBATUuWmdX/lZXv/WyapGGECQdNkekKC0vn0pSwIvcSkfN+hit8wsQ0AmC+tt DbfeBJRhr2aNEFfvxhwu6v1O39eCzY+IgRITN9a0njBT+vrskBcXfzQVwnhbWqUc4bAl XJJRnzylZY9dDyvn/eAiWOtKOe0eqVL1gWqNP5NI0wwchUkTN5UIG73HnZ0hE5Pznnfz zS3peto38ocI6rBz8y4vyuikxOUC/84zerYom2cct1vhM3EU6IKMsY1A9YQlg8l1gtGI 0lHG3GEHDQ1SUxKN3G3gA6ck7dbCi+G/1j1LgH4N4EwPcMSG0y4Y4pwGM0HIqke3VLSi JQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3m8g1s659x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 Dec 2022 02:36:58 +0000 Received: from m0098419.ppops.net (m0098419.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2B62av6X001830; Tue, 6 Dec 2022 02:36:57 GMT Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3m8g1s659p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 Dec 2022 02:36:57 +0000 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.17.1.19/8.16.1.2) with ESMTP id 2B60r9Cn023459; Tue, 6 Dec 2022 02:36:57 GMT Received: from smtprelay07.dal12v.mail.ibm.com ([9.208.130.99]) by ppma01dal.us.ibm.com (PPS) with ESMTPS id 3m9pd9jxjj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 Dec 2022 02:36:56 +0000 Received: from smtpav02.wdc07v.mail.ibm.com (smtpav02.wdc07v.mail.ibm.com [10.39.53.229]) by smtprelay07.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2B62atIM33686220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 6 Dec 2022 02:36:55 GMT Received: from smtpav02.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 79F6458059; Tue, 6 Dec 2022 02:36:55 +0000 (GMT) Received: from smtpav02.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F3AD258058; Tue, 6 Dec 2022 02:36:54 +0000 (GMT) Received: from pike (unknown [9.5.12.127]) by smtpav02.wdc07v.mail.ibm.com (Postfix) with ESMTPS; Tue, 6 Dec 2022 02:36:54 +0000 (GMT) From: Jiufu Guo To: Jeff Law Cc: gcc-patches@gcc.gnu.org, segher@kernel.crashing.org, dje.gcc@gmail.com, linkw@gcc.gnu.org, rguenther@suse.de Subject: Re: [PATCH V2] Use subscalar mode to move struct block for parameter References: <20221117061549.178481-1-guojiufu@linux.ibm.com> <7ea64lroo6.fsf@pike.rch.stglabs.ibm.com> <9424d98e-a95f-58ae-9764-bcf8b4f503dc@gmail.com> <7efseas7f1.fsf@pike.rch.stglabs.ibm.com> <0e432b50-d500-ca2f-0db5-9e9cf099f26c@gmail.com> <7elenuzaak.fsf@pike.rch.stglabs.ibm.com> Date: Tue, 06 Dec 2022 10:36:52 +0800 In-Reply-To: (Jeff Law's message of "Mon, 5 Dec 2022 09:48:13 -0700") Message-ID: <7elenlntq3.fsf@pike.rch.stglabs.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 X-Proofpoint-GUID: USu01tdLDQhXLJKMNNCd2UGpOd_ZTsIa X-Proofpoint-ORIG-GUID: IGg8TYZ19Tscxbqn2A6br-LvmJq25ZY8 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-12-05_01,2022-12-05_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 impostorscore=0 malwarescore=0 bulkscore=0 lowpriorityscore=0 clxscore=1015 phishscore=0 spamscore=0 mlxscore=0 adultscore=0 suspectscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2212060016 X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_MSPIKE_H2,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, Jeff Law writes: > On 11/28/22 20:53, Jiufu Guo wrote: > >>> >>> Right, but the number of registers is target dependent, so I don't see >>> how using "8" or any number of that matter is correct here. >> I understand. And even for the same struct type, using how many >> registers to pass a parameter, it also dependends on the size of the >> parameter and how many leading parameters there is. >> So, as you said, "8" or any numbers are not always accurate. >> >> Because, the enhancement in this patch is just make "block move" to be >> more friendly for follow optiomizations(cse/dse/dce...) by moving >> through sub-mode. So, I just selected one arbitrary number which may >> not too large and also tolerable. >> I also through to query the max number registers from targets for >> param/ret passing, but it may not very accurate neither. >> >> Any sugguestions are welcome! and thanks! > OK, so it's just a magic number and (in theory) any number should > still generate correct code -- the number merely places limits on when > we'll consider performing this optimization. Right. > > It may be overkill, but you might consider making it a PARAM that can > be adjusted. Yes. I also feel the magic number is not perfect. I'm thinking of a way to mark if a param is stored to stack from the register when setup, and then reference the marker during this optimization. This would be more accurate and able to avoid the magic number. > > >> >> For this patch, only simple stuffs are handled like "D.xxx = param_1", >> where the source and dest of the assignment are all in memory which is >> the DECL_RTL(of D.xx/param_xx) in MEM_P/BLK. >> And to avoid complicate, this patch only handle the case where >> "(size % mode_size) == 0". >> >> If any misunderstandings, please point out, thanks. >> And thanks for comments! > How values are justified varies on the PA depending on whether the > parameter is passed in registers or in memory. Though thinking more > about things, I don't think you're changing how the parameter is > passed. Just how it's subsequently pulled out of memory. Right! Thanks a lot for your comments! BR, Jeff (Jiufu) > > jeff