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 BF8C03858C2C for ; Tue, 4 Jul 2023 02:08:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BF8C03858C2C 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 (m0353728.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3641l5uZ029906; Tue, 4 Jul 2023 02:08:37 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=U+Dc4gmp1ZU21hs/G3h2LQUKe47KjvjvTyMgKYmcolM=; b=IyExIFcNyYam2UZXfrc6vHu1iVW+OKL1FQG+FCTIYzN4At1wh5/N8nwZ355JFtShXUg/ pV/Yqm3SJcLM5/4ApKOUIzxssbyMTR5jlkLe2D2+Fwdq5ra0LopEdmqTRMnBjMRl4Vib alE91m9zIWPvi3/TryPp4ZfNDUbHAfwZz/VIO7Wuhl4uaqJS+dcpMIhYpkPhx8N/gdwV 7h2AgDFouNezBRwuzmX9hBYQkwv3mltv1vtAK7bKEnG3TR7loVvRHem2mxKpWeoSl3VB c7cY1ODdx2egHmFjKcqNRhyZt3nlxPeP55U2mbnT2MJ7Nc8E41mhkjQJ7ezcQx0XU/kS WA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3rma2g8f1q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 04 Jul 2023 02:08:37 +0000 Received: from m0353728.ppops.net (m0353728.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 3641ldHn031796; Tue, 4 Jul 2023 02:08:37 GMT Received: from ppma04ams.nl.ibm.com (63.31.33a9.ip4.static.sl-reverse.com [169.51.49.99]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3rma2g8f0k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 04 Jul 2023 02:08:36 +0000 Received: from pps.filterd (ppma04ams.nl.ibm.com [127.0.0.1]) by ppma04ams.nl.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 3640KMBI026591; Tue, 4 Jul 2023 02:08:34 GMT Received: from smtprelay05.fra02v.mail.ibm.com ([9.218.2.225]) by ppma04ams.nl.ibm.com (PPS) with ESMTPS id 3rjbs4sr6y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 04 Jul 2023 02:08:34 +0000 Received: from smtpav04.fra02v.mail.ibm.com (smtpav04.fra02v.mail.ibm.com [10.20.54.103]) by smtprelay05.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 36428WFJ2622000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 4 Jul 2023 02:08:32 GMT Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 020F820040; Tue, 4 Jul 2023 02:08:32 +0000 (GMT) Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2342E20043; Tue, 4 Jul 2023 02:08:30 +0000 (GMT) Received: from [9.197.229.139] (unknown [9.197.229.139]) by smtpav04.fra02v.mail.ibm.com (Postfix) with ESMTP; Tue, 4 Jul 2023 02:08:29 +0000 (GMT) Message-ID: Date: Tue, 4 Jul 2023 10:08:28 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH] rs6000: Update the vsx-vector-6.* tests. Content-Language: en-US To: Carl Love Cc: Peter Bergner , Segher Boessenkool , gcc-patches@gcc.gnu.org, David Edelsohn References: <5197d0d8ab5e975ed7e1e928820769e5921f5796.camel@us.ibm.com> <621ac0734ae83c7ca6af00d804a3d3bc2bbbea5b.camel@us.ibm.com> <3f8d0bdc-bddf-d178-ee76-8d41c4b8755f@linux.ibm.com> <4d3135956e493fc12311af8fce18d043769ab7a4.camel@us.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: tvaDkNrevcL0ywrUzODlWfnVsujOCVRC X-Proofpoint-ORIG-GUID: DhqPIBL-8OId4-ptzYPc4XwNnc_k1dUH X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-07-03_17,2023-06-30_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 phishscore=0 clxscore=1015 malwarescore=0 suspectscore=0 adultscore=0 spamscore=0 impostorscore=0 priorityscore=1501 mlxscore=0 mlxlogscore=999 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2307040015 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 Carl, on 2023/7/3 23:57, Carl Love wrote: > Kewen: > > On Fri, 2023-06-30 at 15:20 -0700, Carl Love wrote: >> Segher never liked the above way of looking at the assembly. He >> prefers: >> gcc -S -g -mcpu=power8 -o vsx-vector-6-func-2lop.s vsx-vector-6- >> func- >> 2lop.c >> >> grep xxlor vsx-vector-6-func-2lop.s | wc >> 34 68 516 >> >> So, again, I get the same count of 34 on both makalu and genoa. But >> again, that doesn't agree with what make script/scan-assembler thinks >> the counts should be. >> >> When I looked at the vsx-vector-6-func-2lop.s I see on BE: >> >> .... >> lxvd2x 0,10,9 >> xxlor 0,12,0 >> xxlnor 0,0,0 >> ... >> >> I was guessing that it was adjusting the data layout from the load. >> But looking again more carefully versus LE: >> >> .... >> lxvd2x 0,31,9 >> xxpermdi 0,0,0,2 >> xxlor 0,12,0 >> xxlnor 0,0,0 >> xxpermdi 0,0,0,2 >> .... >> >> the xxpermdi is probably what is really doing the data layout change. >> >> So, we have the issue that looking at the assembly gives different >> instruction counts then what >> >> dg-final { scan-assembler-times {\mxxlor\M} } >> >> comes up with??? Now I am really confused. I don't know how the >> scan- >> assembler-times works but I will go see if I can find it and see if I >> can figure out what the issue is. I would expect that the scan- >> assembler is working off the --save-temp files, which get deleted as >> part of the run. I would guess that scan-assembler does a grep to >> find >> the instructions and then maybe uses wc to count them??? I will go >> see >> if I can figure out how scan-assembler-times works. > > OK, I figured out why I was getting 34 xxlor instructions instead of > the 22 that the scan-assembler-times was getting. The difference was > when I compiled the program I forgot to use -O2. So with -O2 I get the > same number of xxlor instructins as scan-assembler-instructions. I get > 34 if I do not specify optimization. OK, thanks for looking into it. When you run a test case with RUNTESTFLAGS, you can add the "-v" (and even more times) to RUNTESTFLAGS, then you can find the exact compiling commands in the dumping, I usually used this way for reproducing and I hope it can avoid some inconsistency for reproduction. > > So, I think the scan-assembler-times are all correct. > > As Peter says, counting xxlor is a bit problematic in general. We > could just drop counting xxlor or have the LE/BE count qualifier for > the instructions. Your call. Yeah, I agree that counting xxlor in the checking code (from function main) is fragile, but as you said we still want to check expected xxlor generated for bif vec_or, so I'd prefer to separate the existing case into the compiling part and run part, I'll reply with more details to your latest v3. Thanks, Kewen