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