[llvm-bugs] [Bug 40787] New: [llvm-exegesis] All benchmarks of the same opcode should be within eps of eachanother.

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Feb 20 06:10:47 PST 2019


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

            Bug ID: 40787
           Summary: [llvm-exegesis] All benchmarks of the same opcode
                    should be within eps of eachanother.
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: llvm-exegesis
          Assignee: unassignedbugs at nondot.org
          Reporter: lebedev.ri at gmail.com
                CC: clement.courbet at gmail.com, gchatelet at google.com,
                    llvm-bugs at lists.llvm.org

A follow up for https://bugs.llvm.org/show_bug.cgi?id=40715
I'm not sure if this is working as intended or not, but the current clustering
code may still end up clustering together benchmark points that are different.
I.e. after clustering, given a cluster, the points within that cluster may
be more offset from each another than the `-analysis-epsilon=`.

This might be a bug in itself Is it?

If not, i believe i will need to introduce an early stabilization sweep,
i.e. go through all the points, create a [opcode]=>{p0, ...} mapping,
and then go through each opcode in that map, and if there is more than one
point for an opcode, verify that every combination (every 2 points)
of these points is `isNeighbour()`. If not, add all these points for
this opcode into a new unstable cluster.
Thus, the normal clustering logic will skip them.

-- 
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/20190220/3aab67ac/attachment-0001.html>


More information about the llvm-bugs mailing list