[compiler-rt] [llvm] [TypeProf][InstrPGO] Introduce raw and instr profile format change for type profiling. (PR #81691)

Mingming Liu via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 20 16:19:01 PST 2024


================
@@ -71,6 +75,19 @@ uint64_t __llvm_profile_get_data_size(const __llvm_profile_data *Begin,
   return __llvm_profile_get_num_data(Begin, End) * sizeof(__llvm_profile_data);
 }
 
+COMPILER_RT_VISIBILITY
+uint64_t __llvm_profile_get_num_vtable(const VTableProfData *Begin,
+                                       const VTableProfData *End) {
+  intptr_t EndI = (intptr_t)End, BeginI = (intptr_t)Begin;
+  return (EndI + sizeof(VTableProfData) - 1 - BeginI) / sizeof(VTableProfData);
----------------
minglotus-6 wrote:

Originally I implemented `__llvm_profile_get_num_vtable` based on `__llvm_profile_get_num_data`, and the question is around whether/why `sizeof(C struct) - 1` is necessary in the numerator.

>From offline chat, the conclusion (based on reverse reasoning) is that `sizeof(C struct) - 1` is  necessary iff `[Begin, End]` is an inclusive range.
* For example, the function is expected to return 1 but would return 0 if caller passes `<Addr, Addr + sizeof(C-struct) -1>` as the pair of `<Begin, End>`  

>From inspecting the elf sections of `__llvm_prof_cnts` in a simple instrumented hello-world program and looking at pointer values in a debugger, `End` is one byte past the inclusive range (i.e. caller passes `[Begin, End)` as function argument).

So it makes no difference (at least for elf) if we remove `sizeof(C struct) - 1 ` from the numerator. I added a comment in `__llvm_profile_get_num_data` to record the conclusion (but keep existing code as it is) and removed `sizeof()-1` in the new code.

https://github.com/llvm/llvm-project/pull/81691


More information about the llvm-commits mailing list