Re: [PATCH] [testsuite] [powerpc] adjust -m32 counts for fold-vec-extract*

[Segher Boessenkool <segher@kernel.crashing.org>]

Hi!

On Thu, May 25, 2023 at 07:05:55AM -0300, Alexandre Oliva wrote:
> On May 25, 2023, "Kewen.Lin" <linkw@linux.ibm.com> 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