[PATCH] D96434: [CSSPGO][llvm-profgen] Filter out the instructions without location info for symbolizer

Lei Wang via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 11 14:06:21 PST 2021


wlei added inline comments.


================
Comment at: llvm/tools/llvm-profgen/PerfReader.cpp:60
       uint64_t PrevIP = IP.Address;
-      IP.backward();
+      HasNext = IP.backward();
       // Break into segments for implicit call/return due to inlining
----------------
hoy wrote:
> wlei wrote:
> > hoy wrote:
> > > wenlei wrote:
> > > > Since all code addresses for the entire binary is record in a single vector, this `HasNext` check is only going to help for the first/last instruction of the entire binary. 
> > > > 
> > > > Is the problem you're seeing very specific to first/last instruction of the entire binary? I thought instruction without location could happen anywhere..
> > > Yeah, empty inline context should not be uncommon. Is the case where `IP.backward()` resulted in an invalid IP that crashed the `inlineContextEqual` check?
> > > this HasNext check is only going to help for the first/last instruction of the entire binary.
> > >IP.backward() resulted in an invalid IP that crashed the inlineContextEqual check
> > Exactly, you both are right.
> > 
> > > Is the problem you're seeing very specific to first/last instruction of the entire binary? I thought instruction without location could happen anywhere..
> > Yes, it could happen anywhere. if the instruction without location is not the first/ last instruction, it will jump to the next valid address which also get `false` for `inlineContextEqual`, it's fine for that. Only the first/last one, it will be out of boundary.
> > 
> > For our internal tool, it use a fake location, like <function_name, -1> which can ensure `inlineContextEqual` always return false. and I also saw the first/last instruction is always a fake location, so there is no out of boundary issue for it.
> > 
> > An alternative to fix this is to do the same as our internal one, for all the empty location stack, we create a fake location, say <invalid, -1>, then I guess we don't need to check the boundary for `advance` and `backward` (theoretically we should also check but we didn't see the case first/last insn isn't a fake location for our internal tool). One trade-off is it could sightly increase the memory usage. 
> > 
> > Any thoughts on this?
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> Thanks for the explanation. Can this out-of-range issue be fixed by making `inlineContextEqual` always return false for empty stacks? Tweaking `inlineContextEqual` so that no special care to out-of-bound IP sound cleaner to me.
Good point! I forgot it also needs to change `getInlineLeafFrameLoc` and `getExpandedContextStr` for the empty location stack check. 

Submitted the latest diff for the tweaking, ran them on the SPEC, it all passed!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96434



More information about the llvm-commits mailing list