search for: llvm_prf_data

I encountered an issue when enabling code coverage for Android and would like to confirm my findings and ask for suggestions. Here is my finding: When -fprofile-instr-generate, an llvm_prf_data section gets created that has entries for each function in the TU. One of the entries is FunctionAddr which holds the address of the function. Underneath, it is a relocation so it gets patched with the runtime, in-memory address of the function. The whole llvm_prf_data section, or at least the F...

...p to track if the function has been invoked or not. In other words, the runtime overhead of B) could be lower :) David > and the binary and the profile data will be larger since it needs one > number for each function plus additional overhead in the per-function > metadata recorded in llvm_prf_data. The buffer size for option (A) is > controllable, it needs to be the number of functions executed at startup. > > For the Facebook app, we expect that the number of functions executed > during startup is 1/3 to 1/2 of all functions in the binary. Profile data > size is important sin...

...initialized to 0 and the global index can start from 1. >> David >> >> >> >>> and the binary and the profile data will be larger since it needs one >>> number for each function plus additional overhead in the per-function >>> metadata recorded in llvm_prf_data. The buffer size for option (A) is >>> controllable, it needs to be the number of functions executed at startup. >>> >> > Do you have a rough estimation on how much overhead the per-function > metadata is? > > Manman > >> >>> For the Facebook ap...

I would love to see this kind of order profiling support. Using dtrace to generate function orders is actually really problematic because dtrace made tradeoffs in implementation allowing it to ignore probe execution if the performance impact is too great on the system. This can result in dtrace being non-deterministic which is not ideal for generating optimization data. Additionally if order