[PATCH] LLVM changes for indirect call target profiling support

[David]

================
Comment at: include/llvm/ProfileData/InstrProf.h:27
@@ +26,3 @@
+    indirect_call_target = 0,
+    last = 1
+};
----------------
betulb wrote:
> betulb wrote:
> > davidxl wrote:
> > > I suggest change it to 3 with reserved slots for new value profiler in the future.
> > Reservation is not necessary. The current readers/writers and runtime will handle nay additions here w/o any format version change being necessary. Changes will have to happen in the InstrProfiling.cpp in lib/Transforms/Instrumentation to allow the generation of the additional entries.
> I was incorrect here. Either reservation or format version change is necessary for remaining backward compatible with older value profiles. I'll do the reservation.
> 
The size of ValueData depends on it, or am I missing something?  

struct ValueData {
    ProfileData Data;
    const IntPtrT FunctionPointer;
    const uint32_t NumValueSites[instr_value_prof_kind::last];
    const IntPtrT Values[instr_value_prof_kind::last]; // NULL, used at runtime
  };

================
Comment at: include/llvm/ProfileData/InstrProfReader.h:329
@@ +328,3 @@
+      // If we have more counts than data, this is bogus.
+      if (I + NumCounts > NumEntries)
+        return data_type();
----------------
betulb wrote:
> davidxl wrote:
> > No error handling or warning? 
> Errors are handled elsewhere. So the empty data_type() return is done intentionally here. When the getFunctionCounts method sees an empty InstrProfRecord, then it emits malformed data error (code copied below). 
> 
>   // Found it. Look for counters with the right hash.
>   ArrayRef<InstrProfRecord> Data = (*Iter);
>   if (Data.empty())
>     return error(instrprof_error::malformed);
> 
> 
ok, sounds good.

http://reviews.llvm.org/D8908

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/