search for: instrprof_incr

...ate site for PC, they are all marked as aliases in one pass. 3. >> Erase all updates to redundant profile counters. > > 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 == p...

...ases in one pass. > > > 3. > > >> Erase all updates to redundant profile counters. > > > > 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 n...

...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 as some other profile counter. Consider the following module: local void f1() { instrprof_increment(profc_f1); } void f2() { instrprof_increment(profc_f2); f1(); } Once the inliner runs and deletes f1, we're left with: void f2() { instrprof_increment(profc_f2); instrprof_increment(profc_f1); } Now we can say profc_f1 is redundant (or, an al...

...gt; >> Erase all updates to redundant profile counters. >> > > >> > > 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...

...t;> >> Problem Overview >> ================ >> >> A profile counter is redundant if it's incremented in exactly the same >> basic >> blocks as some other profile counter. Consider the following module: >> >> local void f1() { >> instrprof_increment(profc_f1); >> } >> >> void f2() { >> instrprof_increment(profc_f2); >> f1(); >> } >> >> Once the inliner runs and deletes f1, we're left with: >> >> void f2() { >> instrprof_increment(profc_...

...== >>>> >>>> A profile counter is redundant if it's incremented in exactly the same >>>> basic >>>> blocks as some other profile counter. Consider the following module: >>>> >>>> local void f1() { >>>> instrprof_increment(profc_f1); >>>> } >>>> >>>> void f2() { >>>> instrprof_increment(profc_f2); >>>> f1(); >>>> } >>>> >>>> Once the inliner runs and deletes f1, we're left with: >>&gt...

...intrinsics in the frontend, and produce the counters later in the pipeline to avoid duplicate counters. I didn't completely follow that discussion; I haven't spent much time looking at the counter intrinsics or how they're lowered. Just to recap: the frontend emits calls to the llvm.instrprof_increment intrinsic to implement counter updates. Each increment intrinsic is passed a function name and a counter index (there's a mapping between AST nodes and counter indices). The intrinsics are lowered in the InstrProfiling pass. During lowering, an array of uint64_t counters is created for eac...

...time.start @llvm.lifetime.end @llvm.invariant.start @llvm.invariant.end @llvm.invariant.group.barrier @llvm.var.annotation @llvm.ptr.annotation @llvm.bitset.test Words with underscores (except for the initial namespace prefix): @llvm.read_register @llvm.write_register @llvm.clear_cache @llvm.instrprof_increment @llvm.instrprof_value_profile Thanks again, Hal -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory

...frontend, and produce the counters later in the pipeline to avoid duplicate counters. I didn't completely follow that discussion; I haven't spent much time looking at the counter intrinsics or how they're lowered. >> >> Just to recap: the frontend emits calls to the llvm.instrprof_increment intrinsic to implement counter updates. Each increment intrinsic is passed a function name and a counter index (there's a mapping between AST nodes and counter indices). The intrinsics are lowered in the InstrProfiling pass. During lowering, an array of uint64_t counters is created for eac...

...BB. The above three steps are the same for profile-generate and profile-use compilation. In the next step, for profile-generation compilation, all the edges that not in the MST are instrumented. If this is a critical edge, split the edge first. The actual instrumentation is to generate Intrinsic::instrprof_increment() in the instrumented BB. This intrinsic will be lowed by pass createInstrProfilingPass(). In the next step, for profile-generation compilation, all the edges that not in the MST are instrumented. If this is a critical edge, split the edge first. The actual instrumentation is to generate Intr...

...enerate and profile-use >> compilation. >> >> In the next step, for profile-generation compilation, all the edges that >> not in the MST are instrumented. If this is a critical edge, split the edge >> first. The actual instrumentation is to generate >> Intrinsic::instrprof_increment() in the instrumented BB. This intrinsic >> will be lowed by pass createInstrProfilingPass(). >> >> In the next step, for profile-generation compilation, all the edges that >> not in the MST are instrumented. If this is a critical edge, split the edge >> first. Th...

...>> > >>> In the next step, for profile-generation compilation, all the edges > that > >>> not in the MST are instrumented. If this is a critical edge, split the > edge > >>> first. The actual instrumentation is to generate > >>> Intrinsic::instrprof_increment() in the instrumented BB. This > intrinsic will > >>> be lowed by pass createInstrProfilingPass(). > >>> > >>> In the next step, for profile-generation compilation, all the edges > that > >>> not in the MST are instrumented. If this is a cr...

Justin, Sean and other people interested in this proposal, I'm wondering if you have chances to read the new experiment results in my last email sent 2 weeks ago. Can you share you thoughts, or you have other tests that you want to to run? I'm in the final stage of preparing the patch. If you are OK, I can sent out the patch soon. Thanks, -Rong On Wed, Aug 19, 2015 at 5:18 PM, Philip