[PATCH] D20408: [profile] entry eviction support in value profiler

[David Li via llvm-commits]

davidxl marked 4 inline comments as done.

================
Comment at: lib/profile/InstrProfilingValue.c:108
@@ -101,3 +107,3 @@
       CurrentVNode->Count++;
       return;
     }
----------------
vsk wrote:
> If `CurrentVNode == MinCountVNode` before this increment, should we check if `MinCountVNode` needs to be replaced before we return? It's not a common case, but I'm concerned about doing `--MinCountVNode->Count` on the wrong node in subsequent calls.
This is by design. This allows the mincount node tracking to be adaptive (can correct previous mistakes) such that it can eventually be locked on the cold one that is in stable state.

================
Comment at: test/profile/Inputs/instrprof-value-prof-real.c:312
@@ -311,3 +311,3 @@
 // CHECK-NEXT:	[ 0, foo_1_2_2_2_2_2_2_1_2, 747 ]
-// CHECK-NEXT:	[ 0, foo_1_2_2_2_2_2_2_2_1, 746 ]
+// CHECK-NEXT:	[ 0, foo
 // CHECK-NEXT:	[ 1, foo_2_2_2_2_2_2_2_2_2, 2000 ]
----------------
vsk wrote:
> I don't follow why `[0, foo_..., N]` changes to `[0, foo`. Could you explain why this happens?
The test case is a stress test that have > 256 values per site. WIth this change, the last 256 cold targets are competing for this one slot, so it does not matter who survives.


http://reviews.llvm.org/D20408