search for: __llvm_prf_alias

...> information "yes or no" (per line). Justin pointed out that this doesn't > work for a few of Apple's use cases. > > > Clarifications > ============== > > 1. In my original email, two of my numbers were incorrect. I listed the > sizes of the __llvm_prf_alias sections, not the number of actual aliases. > The corrected lines are: > > O3 + PGOInstr + Pruning: 0.606s (8.6% performance win, _42_ aliases) > O3 + CoverageInstr + Pruning: 0.610s (11.6% performance win, _44_ aliases) > > 2. > > >> Determine which profil...

...this >> doesn't >> > work for a few of Apple's use cases. >> > >> > >> > Clarifications >> > ============== >> > >> > 1. In my original email, two of my numbers were incorrect. I listed the >> > sizes of the __llvm_prf_alias sections, not the number of actual >> aliases. >> > The corrected lines are: >> > >> > O3 + PGOInstr + Pruning: 0.606s (8.6% performance win, _42_ >> aliases) >> > O3 + CoverageInstr + Pruning: 0.610s (11.6% performance win, _44_ >> alia...

...ations that are possible if we make coverage information "yes or no" (per line). Justin pointed out that this doesn't work for a few of Apple's use cases. Clarifications ============== 1. In my original email, two of my numbers were incorrect. I listed the sizes of the __llvm_prf_alias sections, not the number of actual aliases. The corrected lines are: O3 + PGOInstr + Pruning: 0.606s (8.6% performance win, _42_ aliases) O3 + CoverageInstr + Pruning: 0.610s (11.6% performance win, _44_ aliases) 2. >> Determine which profile counters are essential. > > Wh...

Hi, I'd like to add a new pass to LLVM which removes redundant profile counter updates. The goal is to speed up code coverage testing and profile generation for PGO. I'm sending this email out to describe my approach, share some early results, and gather feedback. Problem Overview ================ A profile counter is redundant if it's incremented in exactly the same basic blocks