[PATCH] D135914: [PseudoProbe] Decode offset based pseudo probe.
Hongtao Yu via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Oct 25 15:05:12 PDT 2022
hoy added a comment.
In D135914#3883493 <https://reviews.llvm.org/D135914#3883493>, @wenlei wrote:
> In D135914#3882912 <https://reviews.llvm.org/D135914#3882912>, @hoy wrote:
>
>> In D135914#3881607 <https://reviews.llvm.org/D135914#3881607>, @wenlei wrote:
>>
>>> Sentinel probe case isn't covered for both encoding and decoding in any test cases, would be good to have some coverage.
>>
>> Forgot to mention that the updated binary, i.e, inline-cs-pseudoprobe.perfbin, is built with the new encoding. The binary supports a dozen llvm-profgen tests and they all pass with the current decoding changes.
>
> Do we have a split function case in the existing tests? I thought we don't, but if we have, that'd be good enough.
Good point. The test binary func-split.perfbin is updated.
================
Comment at: llvm/lib/MC/MCPseudoProbe.cpp:476
+ // leading probe address or function start address.
+ EncodingIsAddrBased = true;
+ }
----------------
wenlei wrote:
> hoy wrote:
> > wenlei wrote:
> > > Maybe I'm asking the same question as the one on previous patch, but why do we still have cases with absolute address encoded? I thought for main function body we have GUID -> symbol (reverse lookup) -> address; and we have similar way to get address for sentinel for split binary function. The rest should all be offset/delta.
> > This is mainly for downwards-compatibility, i.e. to have new llvm-profgen handle old binaries.
> Ok, makes sense. Like I mentioned in the other patch, add a comment explaining this is for backward compatibility and a todo for removal?
Done.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D135914/new/
https://reviews.llvm.org/D135914
More information about the llvm-commits
mailing list