wlei-llvm wrote: Thanks for the context! > Why not use the existing `-pgo-function-entry-coverage` > (https://discourse.llvm.org/t/instrprofiling-lightweight-instrumentation/59113/14?u=ellishg) > LLVM flag? It takes advantage of the `llvm.instrprof.cover` intrinsic which > has less size and runtime overhead than `llvm.instrprof.increment`.
We do use the `-pgo-function-entry-coverage` in this PR, see [here](https://github.com/llvm/llvm-project/pull/109837/files#diff-bac41c71569f27df21a843bcd74d2e604ed508afbdf141777761dfb545c5d228R666-R667). but furthermore, we skip instrumenting the functions that are covered by sampling PGO profile. > It also supports IRPGO and CSIRPGO while it seems that this PR requires a > sample PGO input. Yeah, as I commented above, unfortunately currently the IRPGO main flag is incompatible with the Sampling PGO flag(also a bit diverged for the pipeline passes), that's why we have to add extra instr passes under sampling PGO pipeline and added a new driver flag. https://github.com/llvm/llvm-project/pull/109837 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
