[llvm-bugs] [Bug 50013] New: x86/uops-CMOV16rm-noreg test fails if run on a CPU for which no scheduling machine model exists

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50013

            Bug ID: 50013
           Summary: x86/uops-CMOV16rm-noreg test fails if run on a CPU for
                    which no scheduling machine model exists
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvm-exegesis
          Assignee: unassignedbugs at nondot.org
          Reporter: llvm at lukegb.com
                CC: clement.courbet at gmail.com, gchatelet at google.com,
                    llvm-bugs at lists.llvm.org

Created attachment 24763
  --> https://bugs.llvm.org/attachment.cgi?id=24763&action=edit
CMOV16rm-uops.yaml

This is annoying, because it means that in release tarballs `make check-all`
will fail with an inscrutable error.

In particular, this fails on amdfam10 machines, such as those used by one of
the machines in the NixOS project's builder pool. The bug report I filed there
was https://github.com/NixOS/nixpkgs/issues/119673.

A copy of the generated CMOV16rm-uops.yaml from the "bad" machine is
https://p.lukegb.com/IdeallyDashingPelican.yaml (also attached here).

This generates, on a debug build, using roughly the command line "llvm-exegesis
-mode=analysis -benchmarks-file=IdeallyDashingPelican.yaml
-analysis-clusters-output-file=- -analysis-numpoints=1":

llvm-exegesis:
/home/lukegb/debugit/llvm-project/llvm/include/llvm/MC/MCSchedule.h:348: const
llvm::MCSchedClassDesc* llvm::MCSchedModel::getSchedClassDesc(unsigned int)
const: Assertion `hasInstrSchedModel() && "No scheduling machine model"'
failed.

---

It looks like the intent when writing the test was to force the CPU model used
to be bdver2, however llvm-exegesis doesn't actually seem to use the mcpu flag
at all for -mode=analysis.

I can see a few possibilities for resolving this, some of which make more sense
than others (and I'm not fully familiar with LLVM to be able to say which of
these make any sense):

1) Split the test in two: one to produce a benchmark model and validate some
aspects of it, and a separate test which uses an in-tree-provided separate file
to check that analysis works.
2) Just skip the test if the current host CPU doesn't have a model available
for it.
   - Note: it would be nice to have llvm-exegesis itself provide a better error
message. I only managed to catch this properly after rebuilding in debug mode,
because it's an assertion failure only. If llvm-exegesis cleanly checked this
invariant then it'd be less problematic. This is a bit orthogonal to fixing the
test because the test would (or at least, should?) still fail even if there was
better error output.

Obviously in the ideal case LLVM would have scheduling models for every CPU in
existence :))

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210417/93bd041d/attachment.html>