This is an archive of the discontinued LLVM Phabricator instance.

[Profile] Support __llvm_profile_set_file_object in continuous mode.
AbandonedPublic

Authored by zequanwu on Jul 30 2021, 4:36 PM.

Details

Reviewers
vsk
davidxl
phosek
Summary

When the new file is empty, always copy to new file, un-map old file, map to new file.
When the new file is non-empty:

  1. If neither %m in LLVM_PROFILE_FILE nor EnableMerge = 0, append old profile to the end of the new profile
  2. If %m in LLVM_PROFILE_FILE and EnableMerge = 1, merging old profile into new profile.
  3. Otherwise, just fail. This is because any of old profile or new file was in appending mode before, not sure if we should merge the first part or the last part of profile.

I'm not sure if we should try to merge in the third case.

Diff Detail

Event Timeline

zequanwu created this revision.Jul 30 2021, 4:36 PM
zequanwu requested review of this revision.Jul 30 2021, 4:36 PM
zequanwu updated this revision to Diff 363237.Jul 30 2021, 4:50 PM
zequanwu edited the summary of this revision. (Show Details)

Update.

vsk added a comment.Aug 2 2021, 3:24 PM

I'm concerned about introducing another copy of the mmap() logic. The ones for Apple vs. non-Apple have already diverged: e.g. the non-Apple one isn't appending profile data in non-merging mode, and it also doesn't handle unlocking a profile on mmap() failure in the same way. If we add a third copy, we may inadvertently introduce new platform-specific behavior differences. I hesitate to ask that that refactoring happen now, but the sooner the better. Wdyt, Zequan?

I'm concerned about introducing another copy of the mmap() logic. The ones for Apple vs. non-Apple have already diverged: e.g. the non-Apple one isn't appending profile data in non-merging mode, and it also doesn't handle unlocking a profile on mmap() failure in the same way. If we add a third copy, we may inadvertently introduce new platform-specific behavior differences. I hesitate to ask that that refactoring happen now, but the sooner the better. Wdyt, Zequan?

Do you mean something like the TODO at https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/profile/InstrProfilingFile.c#L429, moving those platform specific code to InstrProfilingPlatform* files?
The initializeProfileForContinuousMode function already diverges on Apple platform and non-Apple platform. If we want to support __llvm_profile_set_file_object in continuous mode, there will also be one version for Apple and another one for non-Apple.

vsk added a comment.Aug 3 2021, 12:05 PM

I'm concerned about introducing another copy of the mmap() logic. The ones for Apple vs. non-Apple have already diverged: e.g. the non-Apple one isn't appending profile data in non-merging mode, and it also doesn't handle unlocking a profile on mmap() failure in the same way. If we add a third copy, we may inadvertently introduce new platform-specific behavior differences. I hesitate to ask that that refactoring happen now, but the sooner the better. Wdyt, Zequan?

Do you mean something like the TODO at https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/profile/InstrProfilingFile.c#L429, moving those platform specific code to InstrProfilingPlatform* files?

I don't think the TODO goes quite far enough, and instead had in mind a single shared definition of initializeProfileForContinuousMode common to all platforms. Most of the logic is similar, and (in theory, at least) there should only be a single platform target conditional required:

#if defined(__APPLE__)
static const bool useBiasVar = false;
static const bool continuousModeSupported = true;
#elif defined(__ELF__) || defined(_WIN32)
static const bool useBiasVar = true;
static const bool continuousModeSupported = true;
intptr_t INSTR_PROF_PROFILE_COUNTER_BIAS_DEFAULT_VAR = 0;
... (bias var setup logic)
#else
static const bool useBiasVar = false;
static const bool continuousModeSupported = false;
#endif

The initializeProfileForContinuousMode function already diverges on Apple platform and non-Apple platform. If we want to support __llvm_profile_set_file_object in continuous mode, there will also be one version for Apple and another one for non-Apple.

Right, that is exactly what I think we should move away from. Having multiple copies of this logic with subtle platform-specific differences seems like it would pose a high maintenance burden.

I'm concerned about introducing another copy of the mmap() logic. The ones for Apple vs. non-Apple have already diverged: e.g. the non-Apple one isn't appending profile data in non-merging mode, and it also doesn't handle unlocking a profile on mmap() failure in the same way. If we add a third copy, we may inadvertently introduce new platform-specific behavior differences. I hesitate to ask that that refactoring happen now, but the sooner the better. Wdyt, Zequan?

Do you mean something like the TODO at https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/profile/InstrProfilingFile.c#L429, moving those platform specific code to InstrProfilingPlatform* files?

I don't think the TODO goes quite far enough, and instead had in mind a single shared definition of initializeProfileForContinuousMode common to all platforms. Most of the logic is similar, and (in theory, at least) there should only be a single platform target conditional required:

#if defined(__APPLE__)
static const bool useBiasVar = false;
static const bool continuousModeSupported = true;
#elif defined(__ELF__) || defined(_WIN32)
static const bool useBiasVar = true;
static const bool continuousModeSupported = true;
intptr_t INSTR_PROF_PROFILE_COUNTER_BIAS_DEFAULT_VAR = 0;
... (bias var setup logic)
#else
static const bool useBiasVar = false;
static const bool continuousModeSupported = false;
#endif

The initializeProfileForContinuousMode function already diverges on Apple platform and non-Apple platform. If we want to support __llvm_profile_set_file_object in continuous mode, there will also be one version for Apple and another one for non-Apple.

Right, that is exactly what I think we should move away from. Having multiple copies of this logic with subtle platform-specific differences seems like it would pose a high maintenance burden.

I'll try to refactor it in another patch.

zequanwu updated this revision to Diff 364920.Aug 6 2021, 6:20 PM
zequanwu edited the summary of this revision. (Show Details)

Rebase and factor out mmap for continuous mode.
Right now let's keep two versions of __llvm_profile_set_file_object as it's not clear that if we should do appending mode on linux.

Herald added a project: Restricted Project. · View Herald TranscriptAug 6 2021, 6:20 PM
Herald added a subscriber: Restricted Project. · View Herald Transcript
zequanwu added a subscriber: rnk.Aug 10 2021, 2:34 PM
zequanwu updated this revision to Diff 365621.Aug 10 2021, 3:49 PM

Restore a missing test case in previous update.

zequanwu abandoned this revision.Aug 17 2021, 2:23 PM

D108242 is the new one.