search for: getentrycount

...ary >>> module analysis for the top-down part might work around this though) >>> >> >>> >> Wrapping function entry counts behind an analysis might be doable but >> requires more careful thought. >> > > Definitely. > > >> Right now getEntryCount is called from various passes: inliner, loop >> passes (unroll, loop sink), codegenprepare (for function layout), machine >> block placement, module summary analysis ... This might be worth attempting >> when we fully migrate to the new pass manager but not now. >> > >...

...ncrementally as a bottom > up CGSCC analysis which is what CGSCC analyses currently do; an auxiliary > module analysis for the top-down part might work around this though) > > Wrapping function entry counts behind an analysis might be doable but requires more careful thought. Right now getEntryCount is called from various passes: inliner, loop passes (unroll, loop sink), codegenprepare (for function layout), machine block placement, module summary analysis ... This might be worth attempting when we fully migrate to the new pass manager but not now. Also, the need to run this logic (or similar...

...t;>>>> >>>> >>>>> >>>> Wrapping function entry counts behind an analysis might be doable but >>>> requires more careful thought. >>>> >>> >>> Definitely. >>> >>> >>>> Right now getEntryCount is called from various passes: inliner, loop >>>> passes (unroll, loop sink), codegenprepare (for function layout), machine >>>> block placement, module summary analysis ... This might be worth attempting >>>> when we fully migrate to the new pass manager but not...

Functions in LLVM IR have a function_entry_count metadata that is attached in PGO compilation. By using the entry count together with the block frequency info, the compiler computes the profile count of call instructions based on which the hotness/coldness of callsites can be determined. Experiments have shown that using a higher threshold for hot callsites results in improved runtime performance