[PATCH] D113492: [llvm-profgen] Fix bug of split range branch sample

[Wenlei He via Phabricator via llvm-commits]

wenlei added a comment.

In D113492#3119430 <https://reviews.llvm.org/D113492#3119430>, @wlei wrote:

> In D113492#3118908 <https://reviews.llvm.org/D113492#3118908>, @wenlei wrote:
>
>>> However, in HHVM, I found that there are many functions that none of their ranges is set to true
>>
>> Why is this happening? Should we fix this so that for any function, there's always one range that is considered entry?
>
> For example, in HHVM:
> The DWARF function name is "_ZN8facebook6falcon10ProcessKey**C2**ERKS1_"  and the same start address on ELF the symbol name is   " _ZN8facebook6falcon10ProcessKey**C1 <https://reviews.llvm.org/C1>**ERKS1_". The function has only one range.
>
> So there is name difference between DWARF and symbol table even it has only one range. I don't know the root reason for debug info, maybe some change in FE
>
>> Should we fix this so that for any function, there's always one range that is considered entry?
>
> I'm thinking a case even we make the function entry flag correct, there's still a chance to call a non-entry function that should report the count, like "main" --> "foo.V1" , maybe foo.V1 is the function slice covering function start.

That shouldn't happen. Function calls has to go through prolog, and we shouldn't expect to see cross-function transfer in the middle of a function without going through prolog.

> See the change in this patch, try to remove the `isFuncEntry` logic. Instead, we check if the source and start' range is from the same function but different split range.




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113492/new/

https://reviews.llvm.org/D113492