[PATCH] D102246: [SampleFDO] New hierarchical discriminator for Flow Sensitive SampleFDO

Wenlei He via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri May 14 13:54:59 PDT 2021


wenlei added inline comments.


================
Comment at: llvm/lib/CodeGen/FSAFDODiscriminator.cpp:100
+      DiscriminatorCurrPass = DiscriminatorCurrPass << LowBit;
+      DiscriminatorCurrPass += getCallStackHash(BB, I, DIL);
+      DiscriminatorCurrPass &= BitMaskThisPass;
----------------
xur wrote:
> wenlei wrote:
> > xur wrote:
> > > wenlei wrote:
> > > > This seems different from the description in original RFC where you talked about using count of total discriminators and sequential id as seed for a fs-discriminator. Given that we still use inline stack as part of line info, and discriminator is on top of line stack, what extra benefit does hashing the entire inline stack bring us? 
> > > yes. this part has gone through quite some change before and after RFC. Here we still uses a sequential id. 
> > > Add a callstack hash is just one more safety measure to catch the mismatches. 
> > Not a big deal, but I think since we always have line stack, and discriminator always has paired line stack, it doesn't need to have that info captured. Could saving the walk over inlineAt chain? 
> when we insert the discriminator, we just just check the lineno (I meant the tuple of <filename, lineno, discriminator) -- this is not line stack. 
> I did some pretty large build and did not find this part consume much time.
> 
> I'll keep this in mind and gonna revisit in the tuning.
ok, it's fine for now. For existing sample loader, we use nested FunctionSamples to get profile for instruction based on its line stack (`FunctionSamples::findFunctionSamples`), so the use of line stack is implicit there. Not sure if FS sample loader is different. 


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

https://reviews.llvm.org/D102246



More information about the llvm-commits mailing list