From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 520093858D32; Thu, 25 May 2023 11:25:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 520093858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 34PBM22L026274; Thu, 25 May 2023 06:22:03 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 34PBM0qm026273; Thu, 25 May 2023 06:22:00 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 25 May 2023 06:22:00 -0500 From: Segher Boessenkool To: Alexandre Oliva Cc: "Kewen.Lin" , Rainer Orth , Mike Stump , David Edelsohn , Kewen Lin , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] [testsuite] [powerpc] adjust -m32 counts for fold-vec-extract* Message-ID: <20230525112200.GJ19790@gate.crashing.org> References: <0737fbfc-726c-ffca-5f36-d6b3f0decfec@linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: Hi! On Thu, May 25, 2023 at 07:05:55AM -0300, Alexandre Oliva wrote: > On May 25, 2023, "Kewen.Lin" wrote: > > So both lp64 and ilp32 have the same count, could we merge it and > > remove the selectors? > > We could, but... I thought I wouldn't, since they were different > before, and they're likely to diverge again in the future. I thought > that combining them might suggest that they ought to be the same, when > we already know that this is not the case. > > I'll prepare an alternate patch that combines them. Fwiw, updating the insn counts blindly like this has very small value on the one hand, and negative value on the other. In total, negative value. If it is not possible to keep these tests up-to-date easily the test should be improved. If tests regressed otoh we should ***not*** paper over that with patches like this, but investigate what happened instead: such regressions are *real*. So which is it here? I am assuming it is a not-to-well written testcase without all the necessary noipa attrs, and/or putting more than one thing to test per function directly. Insn counts then shift easily if the compiler decides to factor (CSE etc.) your code differently, but that is a testcase artifact then, not something we want to adjust counts for all of the time. It is feasible to do these insn count things only for trivial tiny snippets. Everything bigger will regress all of the time, no one will look at it properly, and instead people will just do blind "update counts" patches like this :-/ *Good* insn count tests are quite valuable, but harder to write. But maintenance costs noticably bigger than zero for a testcase are not good, how many testcases do we run in the testsuite? So, can we fix the underlying problem here please? Thanks, Segher