search for: profc_f2f1_fused

...When you are saying "erase", you need to actually replace the multiple counter increment with *a new* counter, right? I.e. when replacing: > > instrprof_increment(profc_f2); > instrprof_increment(profc_f1); > > you need to emit: > > instrprof_increment(profc_f2f1_fused); No. The pass only erases updates to counters which it can prove are truly redundant. There is no need to create a new (or fused) counter because profc_f1 == profc_f2 in all possible profiles. 4. >> The complexity of this pass is O(N*M), where N is the number of profile >> counters...

...", you need to actually replace the multiple counter increment with *a new* counter, right? I.e. when replacing: > > > > instrprof_increment(profc_f2); > > instrprof_increment(profc_f1); > > > > you need to emit: > > > > instrprof_increment(profc_f2f1_fused); > > > No. The pass only erases updates to counters which it can prove are > truly redundant. There is no need to create a new (or fused) counter > because profc_f1 == profc_f2 in all possible profiles. > > Oh, this makes it substantially less useful I would think (and I mi...

...ment with *a new* counter, right? I.e. when replacing: >> > > >> > > instrprof_increment(profc_f2); >> > > instrprof_increment(profc_f1); >> > > >> > > you need to emit: >> > > >> > > instrprof_increment(profc_f2f1_fused); >> > >> > >> > No. The pass only erases updates to counters which it can prove are >> > truly redundant. There is no need to create a new (or fused) counter >> > because profc_f1 == profc_f2 in all possible profiles. >> > >> > Oh, thi...

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