[Paper Review] Hardware Counted Profile-Guided Optimization

Baptiste Wicht, R Vitillo+2 more|arXiv (Cornell University)|Nov 24, 2014

Parallel Computing and Optimization Techniques3 references3 citations

TL;DR

This paper proposes a sampling-based Profile-Guided Optimization (PGO) technique for GCC that uses hardware performance counters—specifically Last Branch Record (LBR) sampling—combined with debug symbols to reconstruct source-level profiles. It achieves 93% of the performance gains from instrumentation-based PGO with only 1.06% average profiling overhead, compared to 16% for instrumentation, making PGO practical for production use.

ABSTRACT

Profile-Guided Optimization (PGO) is an excellent means to improve the performance of a compiled program. Indeed, the execution path data it provides helps the compiler to generate better code and better cacheline packing. At the time of this writing, compilers only support instrumentation-based PGO. This proved effective for optimizing programs. However, few projects use it, due to its complicated dual-compilation model and its high overhead. Our solution of sampling Hardware Performance Counters overcome these drawbacks. In this paper, we propose a PGO solution for GCC by sampling Last Branch Record (LBR) events and using debug symbols to recreate source locations of binary instructions. By using LBR-Sampling, the generated profiles are very accurate. This solution achieved an average of 83% of the gains obtained with instrumentation-based PGO and 93% on C++ benchmarks only. The profiling overhead is only 1.06% on average whereas instrumentation incurs a 16% overhead on average.

Motivation & Objective

• To overcome the high overhead and complex dual-compilation model of instrumentation-based PGO.
• To enable practical adoption of PGO in real-world projects by reducing profiling overhead.
• To develop a GCC-compatible toolchain that uses hardware performance counters for profile collection.
• To evaluate the accuracy and performance of sampling-based PGO on SPEC 2006 benchmarks.
• To extend PGO support to optimized binaries without requiring recompilation for profiling.

Proposed method

• Sampling Last Branch Record (LBR) events from the Performance Monitoring Unit (PMU) to capture execution traces.
• Using debug symbols to map sampled program counter (PC) values back to source code locations.
• Reconstructing basic block and edge frequencies from LBR samples using a Minimum Control Flow algorithm.
• Normalizing sample counts to account for basic block size and avoid bias toward larger blocks.
• Integrating the sampled profile into GCC via the AutoFDO (AFDO) patch, which supports profile-driven optimizations.
• Using the perf tool to collect samples and the gooda-to-afdo-converter tool to convert raw samples into GCOV-compatible profile files.

Experimental results

Research questions

• RQ1 Can hardware performance counter sampling achieve PGO accuracy comparable to instrumentation-based PGO?
• RQ2 Can sampling-based PGO reduce profiling overhead to a level suitable for production use?
• RQ3 How does the use of LBR sampling and debug symbols affect profile reconstruction accuracy?
• RQ4 Can the proposed method be integrated into existing GCC toolchains without requiring special compilation modes?
• RQ5 What is the impact of sampling-based PGO on real-world application performance, especially in C++ workloads?

Key findings

• The proposed hardware-sampling PGO achieved 83% of the performance gains from instrumentation-based PGO on average across SPEC 2006 benchmarks.
• On C++ benchmarks alone, the technique achieved 93% of the performance gains from instrumentation-based PGO.
• The profiling overhead was only 1.06% on average, compared to 16% for instrumentation-based PGO.
• The method supports optimized binaries and avoids the dual-compilation model required by instrumentation-based PGO.
• The toolchain is production-ready and has been integrated into GCC via the AutoFDO patch.
• The approach enables future exploration of new optimization opportunities using low-level hardware events like load latency and branch misprediction.