[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
Fri Feb 16 12:16:17 PST 2024
================
@@ -273,18 +280,28 @@ lprofWriteDataImpl(ProfDataWriter *Writer, const __llvm_profile_data *DataBegin,
const uint64_t NumBitmapBytes =
__llvm_profile_get_num_bitmap_bytes(BitmapBegin, BitmapEnd);
const uint64_t NamesSize = __llvm_profile_get_name_size(NamesBegin, NamesEnd);
+ const uint64_t NumVTables =
+ __llvm_profile_get_num_vtable(VTableBegin, VTableEnd);
+ const uint64_t VTableSectionSize =
+ __llvm_profile_get_vtable_section_size(VTableBegin, VTableEnd);
+ const uint64_t VNamesSize =
+ __llvm_profile_get_name_size(VNamesBegin, VNamesEnd);
/* Create the header. */
__llvm_profile_header Header;
/* Determine how much padding is needed before/after the counters and after
* the names. */
uint64_t PaddingBytesBeforeCounters, PaddingBytesAfterCounters,
- PaddingBytesAfterNames, PaddingBytesAfterBitmapBytes;
- __llvm_profile_get_padding_sizes_for_counters(
- DataSectionSize, CountersSectionSize, NumBitmapBytes, NamesSize,
- &PaddingBytesBeforeCounters, &PaddingBytesAfterCounters,
- &PaddingBytesAfterBitmapBytes, &PaddingBytesAfterNames);
+ PaddingBytesAfterBitmapBytes, PaddingBytesAfterNames,
+ PaddingBytesAfterVTable, PaddingBytesAfterVNames;
+ if (__llvm_profile_get_padding_sizes_for_counters(
----------------
minglotus-6 wrote:
To clarify a little bit, we don't want to use `llvm_unreachable` to signal errors at least for release builds.
> Also I've usually found for many llvm functions that a bool of true indicates success and false failure which causes the opposite pattern (an explicit bool type isn't necessary for the same behavior).
I agree that using enums has better readability in general. However, given the callers on the chain of the current function regards non-zero (concretely -1) as error and 0 as ok, it's a larger change (that usually goes to a separate PR) to improve the readability using enums. The `true` and `false` interpretation in llvm depends a lot on the caller context based on my experience.
https://github.com/llvm/llvm-project/pull/81691
More information about the llvm-commits
mailing list