[PATCH] Indirect call target profiling compiler-rt changes
mail at justinbogner.com
Mon Jun 15 17:51:07 PDT 2015
"Betul Buyukkurt" <betulb at codeaurora.org> writes:
>>> Index: lib/profile/InstrProfilingBuffer.c
>>> --- lib/profile/InstrProfilingBuffer.c
>>> +++ lib/profile/InstrProfilingBuffer.c
>>> @@ -68,11 +68,14 @@
>>> * Match logic in __llvm_profile_write_file().
>>> + __llvm_profile_value_data *ValueDataBegin = NULL;
>>> /* Calculate size of sections. */
>>> const uint64_t DataSize = DataEnd - DataBegin;
>>> const uint64_t CountersSize = CountersEnd - CountersBegin;
>>> const uint64_t NamesSize = NamesEnd - NamesBegin;
>>> const uint64_t Padding = sizeof(uint64_t) - NamesSize %
>>> + const uint64_t ValueDataSize = 0;
>> I guess this is supposed to do:
> This is correct. However, on the buffer access API's the size of the
> buffer is calculated so that the caller of the write API allocates the
> necessary buffer. A pointer to the buffer is passed back to the write
> function for the data to be dumped to this memory. In my implementation, I
> kept the buffer API's unmodified - other than changing the format to match
> that of version 2's. I'd like to know if a re-alloc on the passed in (char
> *Buffer) be in order as a change to accommodate value profiling's dynamic
> memory needs.
But isn't this completely broken if someone uses value profiling and the
buffer APIs? What happens in that case?
Can we teach __llvm_profile_get_size_for_buffer to calculate the correct
size ahead of time so that a realloc isn't necessary?
More information about the llvm-commits