[PATCH] D125448: [llvm-profgen] Filter out oversized LBR ranges.

[Lei Wang via Phabricator via llvm-commits]

wlei added inline comments.


================
Comment at: llvm/tools/llvm-profgen/ProfiledBinary.h:404
+    auto R = UncondBranchOffsets.upper_bound(Start);
+    return R != UncondBranchOffsets.end() && *R < End;
+  }
----------------
wenlei wrote:
> hoy wrote:
> > wlei wrote:
> > > wlei wrote:
> > > > hoy wrote:
> > > > > wlei wrote:
> > > > > > hoy wrote:
> > > > > > > upper_bound seems to find the first element that is greater than Start. How about element equals to Start?
> > > > > > So you mean it will immediately jump when ip is on the Start's address, then it should be lower_bound?
> > > > > Yeah, lower_bound finds the first element that is not less than Start. It should be fine.
> > > > > 
> > > > > 
> > > > Yeah, that sounds reasonable. The `Start` is actually the LBR's Target,  IMO, the Target should not be an unconditional jmp. I will run on our service to see if we have this case.
> > > Okay.. This indeed happened and it's the HW bug. it can be a function the first inst is a JMP or a JMP follow a call
> > > 
> > > ```
> > > func:
> > > xxxx : JMP
> > > ````
> > > Fixed to lower_bound
> > > Thanks!
> > Thanks for verifying that. Surprised to see it was really hit. I was thinking it'd mostly happen in theory.
> > Target, IMO, the Target should not be an unconditional jmp. 
> 
> jmp->jmp should be valid execution sequence..
Got it, thanks! No big profile changes(profile similarity: 100.000%) comparing to upper_bound, because almost all those large bogus ranges not only cross one unconditional JMP.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125448