[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