[PATCH] D109934: [llvm-profgen] Add duplication factor for line-number based profile
Lei Wang via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Sep 28 12:13:12 PDT 2021
wlei added inline comments.
================
Comment at: llvm/test/tools/llvm-profgen/duplication-factor.test:30
+; clang -O3 -g -fdebug-info-for-profiling test.c -emit-llvm -S -o test.ll
+; # Manually update the discriminator for a duplication-factor whose value is 10 in test.ll. For example: a discriminator value 2(0010) will be changed to 2562(101000000010)
+; clang test.ll
----------------
wenlei wrote:
> I think it's better to have a test that can naturally generate duplication factor. That way it's easier to update the test case in the future if needed. To do that we can grab one of the test cases from loop unrolling, and if we enable fdebug-info-for-profiling, i think we should see duplication factor.
I see, After adding the bigger test case(quick sort program), I found that will naturally generate a duplication factor case. So I just removed this test.
================
Comment at: llvm/tools/llvm-profgen/ProfileGenerator.cpp:503
continue;
+ uint64_t DC = Count * getDuplicationFactor(LeafLoc->Callsite.Discriminator);
FunctionProfile.addCalledTargetSamples(LeafLoc->Callsite.LineOffset,
----------------
wenlei wrote:
> nit: `Count *= getDuplicationFactor(LeafLoc->Callsite.Discriminator)`? Same for other places.
Fixed!
================
Comment at: llvm/tools/llvm-profgen/ProfiledBinary.cpp:220
+ Frame.Callsite.Discriminator =
+ ProfileGenerator::getDiscriminator(Frame.Callsite.Discriminator);
+ }
----------------
wenlei wrote:
> Current this function is only used for dwarf based profile, but is it guaranteed that this path will never be used by pseudo probe? we will need to handle discriminator differently for probe case (extractProbeIndex).
Here the code is guaranteed only used by line-number based because this is the function to generate the `StringBasedCtxKey`.
```
std::shared_ptr<StringBasedCtxKey> FrameStack::getContextKey() {
std::shared_ptr<StringBasedCtxKey> KeyStr =
std::make_shared<StringBasedCtxKey>();
KeyStr->Context = Binary->getExpandedContext(Stack, KeyStr->WasLeafInlined);
...
}
```
================
Comment at: llvm/tools/llvm-profgen/ProfiledBinary.cpp:535-538
- } else {
- Discriminator = DILocation::getBaseDiscriminatorFromDiscriminator(
- CallerFrame.Discriminator,
- /* IsFSDiscriminator */ false);
----------------
wenlei wrote:
> By removing this part, we will have duplication factor as part of location in NameStrings and call stack, is that what we want? Logically, duplication factor does not belong to location.
I checked that our internal tools also used duplication factor this way, i. e decoding it when we need it in profile generation.
Alternatively, we can also have a hash map like {offset, duplication factor} offset2DuplicationFactorMap which can be built on-demand as well, which one do you think is better?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D109934/new/
https://reviews.llvm.org/D109934
More information about the llvm-commits
mailing list