boomanaiden154 wrote: > In general, CSSPGO is meant as a more practical alternative for IRPGO thanks > to i) the use of sampled profile, ii) context-sensitivity. However, IRPGO is > still expected to provide better performance in all cases where it's > applicable thanks to accurate profile information. Due to that, I don't think it makes sense to apply CSSPGO on top of IRPGO, and CMake automation would not permit mixing the two (both implemented as LLVM_BUILD_INSTRUMENTED exclusive options).
Ah. Might've been getting this confused with another technique (maybe IRPGO+instrumented context sensitive PGO?). I remember Google saying in https://discourse.llvm.org/t/practical-compiler-optimizations-for-wsc-workshop-us-llvm-dev-meeting-2023/73998 that a valid pipeline was doing two rounds of profiling with different levels of instrumentation. Thanks for the link to the existing performance results. > With CMake stuff implemented in this diff, it's expected that the amount of > profile information collected would be miniscule (in-tree perf-training only > has a single hello world source file) and inadequate for getting much perf > boost with CSSPGO (it even prints the warning that it needs 6985000.0x more > profile). Right. Not sure if you've seen https://github.com/llvm/llvm-project/pull/78879, but that should allow making that pretty easy to do. There's also https://github.com/llvm/llvm-project/pull/77347 proposing to change the default, but there hasn't really been a consensus on that one. Thank you for the additional information. Sorry for the derailment/noise. https://github.com/llvm/llvm-project/pull/79942 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
