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 B7CD63835839 for ; Fri, 22 Jul 2022 02:23:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B7CD63835839 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 26M0LQVo015389; Fri, 22 Jul 2022 02:22:59 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3hfh9h26h7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Jul 2022 02:22:59 +0000 Received: from m0098404.ppops.net (m0098404.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 26M26lT4015876; Fri, 22 Jul 2022 02:22:58 GMT Received: from ppma01fra.de.ibm.com (46.49.7a9f.ip4.static.sl-reverse.com [159.122.73.70]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3hfh9h26gf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Jul 2022 02:22:58 +0000 Received: from pps.filterd (ppma01fra.de.ibm.com [127.0.0.1]) by ppma01fra.de.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 26M2L2BM027628; Fri, 22 Jul 2022 02:22:56 GMT Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by ppma01fra.de.ibm.com with ESMTP id 3hbmy8yr1h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Jul 2022 02:22:56 +0000 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 26M2MsD521889284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 22 Jul 2022 02:22:54 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E51785204E; Fri, 22 Jul 2022 02:22:53 +0000 (GMT) Received: from [9.197.233.93] (unknown [9.197.233.93]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id 78C8A5204F; Fri, 22 Jul 2022 02:22:52 +0000 (GMT) Message-ID: <11061a26-e6db-2f61-065e-b1c9a32d3181@linux.ibm.com> Date: Fri, 22 Jul 2022 10:22:51 +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/test: Update some cases with -mdejagnu-tune Content-Language: en-US To: Segher Boessenkool Cc: GCC Patches , David Edelsohn , Peter Bergner References: <4847b51d-dde2-916b-27aa-8e63518d66d2@linux.ibm.com> <20220721184806.GK25951@gate.crashing.org> From: "Kewen.Lin" In-Reply-To: <20220721184806.GK25951@gate.crashing.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: cUJ2Qi-dQ8w2UxoybcNNwVdWPlNTF6jK X-Proofpoint-GUID: ugOQ_27XJSe5v-Q7gkOKuUCjoMDqBx_W X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-07-21_28,2022-07-21_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 phishscore=0 spamscore=0 malwarescore=0 lowpriorityscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 bulkscore=0 suspectscore=0 impostorscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2207220006 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, KAM_SHORT, NICE_REPLY_A, 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2022 02:23:02 -0000 Hi Segher, Thanks for the comments! on 2022/7/22 02:48, Segher Boessenkool wrote: > Hi! > > On Wed, Jul 20, 2022 at 05:31:11PM +0800, Kewen.Lin wrote: >> As PR106345 shows, some test cases should be updated with >> -mdejagnu-tune, since their test points are sensitive to >> rs6000_tune, such as: group_ending_nop, loop align (ic), >> float conversion cost etc. > > It does not make sense to require -mdejagnu-tune= if -mdejagnu-cpu= is > already given? What is the failure case? > I think cpu setting only sets tune setting when tune setting isn't explicitly provided as: if (rs6000_tune_index >= 0) tune_index = rs6000_tune_index; else if (cpu_index >= 0) rs6000_tune_index = tune_index = cpu_index; As PR106345 shows, GCC can use an explicit tune setting when it's configured, even if there is one "-mdejagnu-cpu=", it doesn't override the explicit given one, so we need one explicit "-mdejagnu-tune=". One failure example is gcc.target/powerpc/loop_align.c See function rs6000_loop_align: /* Implement LOOP_ALIGN. */ align_flags rs6000_loop_align (rtx label) { ... /* Align small loops to 32 bytes to fit in an icache sector, otherwise return default. */ if (ninsns > 4 && ninsns <= 8 && (rs6000_tune == PROCESSOR_POWER4 || rs6000_tune == PROCESSOR_POWER5 || rs6000_tune == PROCESSOR_POWER6 || rs6000_tune == PROCESSOR_POWER7 || rs6000_tune == PROCESSOR_POWER8)) return align_flags (5); else return align_loops; Although the test case has adopted option "-mdejagnu-cpu=power7", but the configured "--with-tune-64=power9" takes effect and make it return align_loops instead of align_flags (5). >> This patch is to replace -mdejagnu-cpu with -mdejagnu-tune >> or append -mdejagnu-tune (keep the original -mdejagnu-cpu >> when it's required) accordingly. > > It is *always* required. Testcases with -mtune= but unspecified -mcpu= > make no sense. > The loop_align.c testings made me think if we know the insn count for the loop on all cpus is in range (4,8] then the cpu setting doesn't matter. I think I get your point, it's risky to assume that even if it works for all existing cpus, will update with an explicit -mdejagnu-cpu here. >> --- a/gcc/testsuite/gcc.target/powerpc/compress-float-ppc-pic.c >> +++ b/gcc/testsuite/gcc.target/powerpc/compress-float-ppc-pic.c >> @@ -1,5 +1,5 @@ >> /* { dg-do compile { target powerpc_fprs } } */ >> -/* { dg-options "-O2 -fpic -mdejagnu-cpu=power5" } */ >> +/* { dg-options "-O2 -fpic -mdejagnu-cpu=power5 -mdejagnu-tune=power5" } */ >> /* { dg-require-effective-target fpic } */ > > This should only make a difference if you have -mtune= in your > RUNTEST_FLAGS, and you shouldn't do silly things like that. I suspect > you see it in other cases, and those are actual bugs then, that need > actual fixing instead of sweeping under the carper. > Unfortunately it's due to the explicit tune setting in configuration. > The testcase suggests this is with a compiler configured with > --with-cpu= --with-tune=, which should just work, and -mcpu= should > override both of those! > Unfortunately -mcpu= (-mdejagnu-cpu=) doesn't actually override here. BR, Kewen