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 3E476384AB58 for ; Fri, 3 May 2024 21:31:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3E476384AB58 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 3E476384AB58 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=1714771896; cv=none; b=BKSjxMCwMLMbLbAzZNer3jVAIqiyJWFXES08nDy/Afq3V4VMsKnSyk/g3dqaTUCOjDerbqclxXv3DiVrFjnefz1UXjuM9H2fcV+E5RvGqArTEZdqMY0S9DCwo2pvoWoTqKhn8Wu5iCF8lf5+t5GsDQAmy7v00Z7UkuYgEgKS62Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714771896; c=relaxed/simple; bh=6AW6oMPhWdJDeECcy3hqQ1WRmdaZsGBXN3C/epogjbc=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=AWT1/uBnjRWS9y7eT6PmXFBko7CWG6+JjnQO8EDCNOjLU3it7aAAjsKyYA3qnNagLV6rpa2wGaB479G1g2YqwJre/Tda8Qc3OfvWdVJGqqC6BxZaMp5N4UnPRsEKQj2WnUYSNiwva/2M0tUX9HlqXM29VV4MEPnKMkBViaEuTjo= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0353729.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 443LRPJv032673; Fri, 3 May 2024 21:31:33 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : references : from : cc : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=pK7T44wrim6Ct3XTKo0qfQqQ69wftf0xTPqx3YOyNeU=; b=JupOgru+B+7ivSGu4U3PGWrb1loOlpC8n4DUiRueCDC0jhFoznJwLzqMmOcPi8IRa2dN 4s1dpADaAgnz98KWA7Jblu3Awqjt+++WlAnZUwQQ/3Una1SNBEVN32Wm0XFqthzEpByB Plk3C47Y1O7ga7b0crV0eakEsc6Lr+sRC3Hz75g9hXobZ94WyZuMHO1MH91B1wZeyaNt ovXSsG26OWO96I8CHG52zu/0YtO/+bNZngtpSSreMlBFevMp26Xnf/RxSNEs7ujchUDL yTppQ7wjai3qWxDI2lAO+5DDuTtVHrDrYBxp0g3Eo+sX0yMjgMdrxBJnBXy1ARK9cLMV 9A== Received: from ppma21.wdc07v.mail.ibm.com (5b.69.3da9.ip4.static.sl-reverse.com [169.61.105.91]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3xw7uqg078-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 03 May 2024 21:31:32 +0000 Received: from pps.filterd (ppma21.wdc07v.mail.ibm.com [127.0.0.1]) by ppma21.wdc07v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 443KKBU6003210; Fri, 3 May 2024 21:31:31 GMT Received: from smtprelay04.dal12v.mail.ibm.com ([172.16.1.6]) by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 3xscpq02xa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 03 May 2024 21:31:31 +0000 Received: from smtpav05.dal12v.mail.ibm.com (smtpav05.dal12v.mail.ibm.com [10.241.53.104]) by smtprelay04.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 443LVS4D12648966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 3 May 2024 21:31:30 GMT Received: from smtpav05.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 66E2558056; Fri, 3 May 2024 21:31:28 +0000 (GMT) Received: from smtpav05.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0A90958052; Fri, 3 May 2024 21:31:28 +0000 (GMT) Received: from [9.61.161.194] (unknown [9.61.161.194]) by smtpav05.dal12v.mail.ibm.com (Postfix) with ESMTP; Fri, 3 May 2024 21:31:27 +0000 (GMT) Message-ID: Date: Fri, 3 May 2024 16:31:27 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [V3] powerpc: Optimized strncmp for power10 To: Amrita H S References: <20240429095847.3541150-1-amritahs@linux.vnet.ibm.com> Content-Language: en-US From: Peter Bergner Cc: libc-alpha@sourceware.org, Paul E Murphy , Adhemerval Zanella In-Reply-To: <20240429095847.3541150-1-amritahs@linux.vnet.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: xakQu9vp6xLG-lZTf0x3YapDPD9Qp0GK X-Proofpoint-GUID: xakQu9vp6xLG-lZTf0x3YapDPD9Qp0GK X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1011,Hydra:6.0.650,FMLib:17.11.176.26 definitions=2024-05-03_15,2024-05-03_02,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=972 clxscore=1011 mlxscore=0 impostorscore=0 adultscore=0 suspectscore=0 bulkscore=0 phishscore=0 lowpriorityscore=0 priorityscore=1501 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2404010000 definitions=main-2405030153 X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,KAM_NUMSUBJECT,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 4/29/24 4:58 AM, Amrita H S wrote: > +++ b/sysdeps/powerpc/powerpc64/le/power10/strncmp.S > @@ -0,0 +1,271 @@ > +/* Optimized strncmp implementation for PowerPC64/POWER10. > + Copyright (C) 2021-2023 Free Software Foundation, Inc. This is a new file, so I believe the Copyright date should just be "2024". > +++ b/sysdeps/powerpc/powerpc64/multiarch/strncmp-power10.S > @@ -0,0 +1,25 @@ > +/* Copyright (C) 2016-2023 Free Software Foundation, Inc. Likewise. > +ENTRY_TOCLESS (STRNCMP, 4) > + /* Check if size is 0. */ > + cmpdi cr0,r5,0 > + beq cr0,L(ret0) > + andi. r7,r3,4095 > + andi. r8,r4,4095 > + cmpldi cr0,r7,4096-16 > + cmpldi cr1,r8,4096-16 > + bgt cr0,L(crosses) > + bgt cr1,L(crosses) > + COMPARE_16(v4,v5,0) > + addi r3,r3,16 > + addi r4,r4,16 This code looks like it assumes the kernel is using a 4k page size. All distros that I know of and the default kernel config for ppc64 and ppc64le kernels is to use a 64K HW page size. Is there a reason we're not checking for a 64k cache boundary here? Adhemerval, you seem to have added the first power8 strncmp.S optimized routine (sysdeps/powerpc/powerpc64/power8/strncmp.S) and that also uses a 4k page boundary. Do you remember the history of why we checked for a 4k page boundary rather than 64k? Was is a matter of using 64k showed no improvement over 4k and using 4k meant we didn't have to worry about some system maybe running in 4k page size kernels? Peter