PG-MDP: Profile-Guided Memory Dependence Prediction

• The paper introduces PG-MDP, which uses profiling to identify and label memory-independent loads, thereby reducing false dependencies and narrowing the predictor working set.
• PG-MDP employs an opcode-based approach to bypass memory dependence prediction, decreasing MDP queries by up to 79% and enhancing performance on small cores.
• The technique achieves competitive IPC gains and power reductions without additional instruction bandwidth or area cost, demonstrating its practical impact in out-of-order execution.

Profile-Guided Memory Dependence Prediction (PG-MDP) is a software/hardware co-design for memory dependence prediction (MDP) on area-constrained out-of-order cores. It labels consistently memory-independent loads via their opcode and removes them from the MDP working set, so that those loads bypass querying the MDP when dispatched and always issue as soon as possible. The central premise is that, for small predictors, the dominant issue is not only limited capacity but also an overly broad working set of instructions being tracked; by removing loads that are actually memory-independent or have sufficiently long store distances, PG-MDP reduces aliasing, false dependencies, and unnecessary stalls without additional instruction bandwidth or area cost (Panayi et al., 9 Apr 2026).

1. Problem formulation and conceptual basis

Memory Dependence Prediction is a speculative technique to determine which stores, if any, a given load will depend on. In an out-of-order core, loads are dispatched into the load queue and typically query the MDP to determine which older stores they must wait for. If the predictor says a load depends on a store, the load stalls until that store resolves. This is beneficial when the dependence is real, but harmful when the dependence is false (Panayi et al., 9 Apr 2026).

A false dependency occurs when a load is stalled on a store that will not actually overlap its address. The papers attribute this especially to small predictors such as Store Sets, where predictor tables are small, many different PCs map to the same predictor entry, unrelated loads and stores alias in the table, and the predictor conservatively reuses the same store-set ID for colliding instructions. The resulting behavior is more MDP queries, more false dependencies, more waiting in the pipeline, and lower IPC (Panayi et al., 9 Apr 2026).

PG-MDP reframes this as a working-set reduction problem. Instead of enlarging the predictor or increasing predictor complexity, it targets the predictor working set by excluding loads that do not need dynamic help. A closely related earlier formulation used compiler static analysis in LLVM to identify loads with no dependencies and label them via their opcode, so that they skip making lookups into the MDP; that work characterized the same benefits as fewer MDP lookups and fewer false dependencies, especially for Store Sets under capacity pressure and PC-index collisions (Panayi et al., 2024).

This suggests that PG-MDP extends a broader idea: hardware MDPs are most valuable for hard cases, while software can pre-classify a substantial subset of easy cases and remove them from predictor contention.

2. Architectural setting: Store Sets, predictor aliasing, and false dependencies

The architectural background is centered on Store Sets and a XiangShan-style Store Sets variant. Store Sets uses a PC-indexed Store Set ID Table (SSIT) and a Last-Fetched Store Table (LFST). When a load dispatches, it PC-indexes into the SSIT; if the entry says it belongs to a store set, the load may be delayed behind the relevant predicted store or stores. This reduces violations, but if unrelated loads collide in the SSIT, a false dependency is created (Panayi et al., 2024).

The 2024 study emphasizes that small SSITs are more collision-prone, false dependencies reduce performance, and clearing periods are needed to avoid predictor saturation. The 2026 study describes the same underlying mechanism in terms of working-set pressure: with small tables, different load PCs hash to the same SSIT entry, a memory-independent load can inherit the SSID of an unrelated dependent load, and the processor inserts a stall even though the load could have issued early (Panayi et al., 9 Apr 2026).

The 2026 evaluation spans three core sizes. For the small core, the configuration is ROB 128, IQ 77, LQ 38, SQ 22, fetch/commit width 4, issue width 8, XS Store Sets 64 SSIT / 32 LFST / 2 slots, and store-distance threshold 8. For the medium core, it is ROB 256, IQ 154, LQ 77, SQ 54, fetch/commit width 6, issue width 8, XS Store Sets 256 SSIT / 128 LFST / 2 slots, and threshold 13. For the large core, it is ROB 512, IQ 308, LQ 154, SQ 108, fetch/commit width 8, issue width 12, PHAST 128 rows, 4-way associativity, 16 tag bits, and threshold 51. The simulator also uses TAGE-SC-L branch predictor sizes of 64 KB or 128 KB depending on core, and a DCPT prefetcher (Panayi et al., 9 Apr 2026).

A central trade-off accompanies small tables and predictor clearing. Reducing the clear period can reduce lingering stale mappings, but it increases memory-order violations because the predictor forgets real dependencies sooner and must relearn them more often. PG-MDP addresses the same pressure point by reducing the number of loads that enter the predictor at all, rather than by relying on larger structures or more aggressive clearing (Panayi et al., 9 Apr 2026).

3. Profiling methodology and store-distance selection

PG-MDP is a profile-guided optimization that identifies loads that are consistently memory-independent or have sufficiently long store distances, then marks those loads in the binary using an alternate opcode. The high-level workflow is: compile with instrumentation, run profiling on training inputs, measure each load’s store distance behavior, select loads to label, recompile with alternate load opcodes, and at runtime let labelled loads bypass the MDP and issue immediately (Panayi et al., 9 Apr 2026).

The paper defines store distance for a load as the number of older in-flight stores in the store queue between the load and the store it truly depends on. If a load has no dependent store in the observed store queue, its store distance is treated as $\infty$. Formally, let $x$ be the address of a load, and let the store queue contain store addresses $y_1, y_2, \dots, y_n$ ordered from youngest to oldest. The store distance is the minimum index $i$ such that $x = y_i$, and if no such $i$ exists, the store distance is $\infty$ (Panayi et al., 9 Apr 2026).

The profiler records store distances across executions and chooses a profiled store distance for each load. If one distance appears in 95% or more of executions across all training inputs, that distance is selected; otherwise, the shortest observed distance is chosen conservatively. A distance threshold is then applied, and loads with sufficiently long store distances, including infinite distance, are selected for labelling. Threshold selection is performed by binary search over candidate store-distance thresholds, choosing the one that maximizes average performance on training inputs for the target processor; the method intentionally uses a single threshold per processor rather than a per-workload threshold (Panayi et al., 9 Apr 2026).

The long-store-distance heuristic is reported to capture four behaviors: memory independent loads, rarely dependent loads, structurally independent loads, and fast-to-resolve dependencies. The technique always labels behavior type (1), while types (2)–(4) depend on the chosen threshold and the target processor’s timing characteristics, especially queue sizes and dispatch/issue timing (Panayi et al., 9 Apr 2026).

The paper argues that static analysis cannot reliably identify all the useful loads. In particular, perfect alias analysis could only capture some independent loads, perfect dependence analysis would be needed for rarely-dependent loads, and no conventional static analysis captures the fast-to-resolve dependency pattern well. A plausible implication is that PG-MDP is designed not merely as a stronger classifier, but as a classifier aligned to speculative execution semantics: occasional mistakes are acceptable because memory-order violation rollback remains in place (Panayi et al., 9 Apr 2026).

4. Encoding, dispatch behavior, and correctness model

The implementation mechanism is opcode-based. Labelled loads are emitted with an alternate opcode; the opcode acts as an ISA-level hint; the processor recognizes the opcode and bypasses the MDP query path at dispatch; the load does not occupy predictor lookup bandwidth and does not take part in MDP table aliasing; and it issues immediately, as early as register dependencies and LSQ constraints allow. If such a load later turns out to conflict with an older store to the same address, the processor detects the memory-order violation as usual, flushes and replays from the violating load onward, but does not create a new MDP entry for that labelled load (Panayi et al., 9 Apr 2026).

The earlier LLVM-based design used a minimally intrusive communication path from compiler to CPU. LLVM attached the label using AAMDNodes metadata because this metadata survives lowering from IR to machine code, and in the AArch64 backend a second pass scanned machine loads and replaced the opcode of a marked load with a new labeled load opcode. The resulting labeled load behaved exactly like a normal load except that it skipped MDP lookup, issued as soon as possible, and did not insert itself into the MDP if it later caused a violation (Panayi et al., 2024).

Both formulations stress the same correctness model. The technique changes speculative scheduling, not architectural results. Correctness is preserved because the load still goes through normal ordering checks later, and if it was dependent and executed too early, the violation is detected and recovery happens as usual (Panayi et al., 2024).

The co-design assumptions are explicit. A target processor must be known well enough to choose a good store-distance threshold, binaries must be recompiled with profile data, the ISA must have room for alternate opcodes to encode the label without extra instruction width, and the processor must distinguish labelled from unlabelled loads in dispatch logic. The 2026 paper notes that the opcode approach is zero additional instruction bandwidth and zero area cost, but may be ISA-dependent; it is more natural for RISC-V-like designs than for encodings with little free opcode space, such as x86 (Panayi et al., 9 Apr 2026).

5. Quantitative results and operating regimes

The 2026 evaluation uses SPEC2017 CPU intspeed workloads, with up to 10 simpoints, 100M instruction intervals, and 10M instruction warm-up. The primary comparison baseline is the unmodified MDP predictor: XS Store Sets at varying sizes for the small and medium core studies, and PHAST on the large core. The study also compares against much larger predictor configurations, especially a 1024-entry Store Sets-style predictor (Panayi et al., 9 Apr 2026).

Across SPEC2017 CPU intspeed, PG-MDP reduces the rate of MDP queries by 79% in the abstract and around 77% in the detailed evaluation discussion, and it reduces false dependencies by 77% on average. The qualitative takeaway is that only about 25% of the original predictor working set needs to be tracked in hardware once the consistently independent loads are removed (Panayi et al., 9 Apr 2026).

For the small core, a 64-entry XS Store Sets predictor with PG-MDP improves geomean IPC by 1.47%. The paper states that this brings performance to within 0.46% of a 1024-entry predictor in one place and rounds this in the abstract to within 0.5%; it also states that a 64-entry predictor with PG-MDP reaches nearly the same IPC as the 1024-entry predictor, and that the 128-entry case captures almost all available IPC. For the medium core, 64 entries with PG-MDP are reported to be 0.72% below the 1024-entry predictor. Per-workload gains are uneven: some workloads gain almost nothing, while others improve by as much as 5.4%–5.6% IPC. The biggest winners are 625.x264_s, 641.leela_s, and 620.omnetpp_s, which are also the workloads with the highest initial false-dependency rates (Panayi et al., 9 Apr 2026).

Power results are also reported. For the small and medium cores, total core power reduction is roughly proportional to IPC gain because the MDP is a relatively small part of total power; specifically, the small core shows 1.45% power reduction for the 1.47% IPC gain. On the large core with PHAST, MDP power was about 1.75% of LSQ power, PG-MDP reduced PHAST queries by 57%, PHAST power fell by 35%, and relative MDP power reached about 1.1% of LSQ power while maintaining IPC (Panayi et al., 9 Apr 2026).

The read-port sensitivity study models a 2-read-port MDP on the small core. Under that constraint, the geomean IPC gain rises from 1.47% to 1.71%, and PG-MDP can slightly help even at larger predictor sizes because labelled loads do not consume predictor ports. This indicates that the method can reduce not only false dependencies but also predictor bandwidth pressure (Panayi et al., 9 Apr 2026).

An earlier static-analysis study reported a smaller but directionally consistent result profile: average reduction in MDP lookups per kilo-instruction of 13%, peak reduction of 62%, geometric mean speedup up to 0.7%, and individual speedups as high as 3.8%. It also observed that positive performance effects were mostly seen on smaller predictor configurations and highlighted 625.x264_s and 641.leela_s as notable gainers on the small CPU (Panayi et al., 2024).

6. Relation to static-analysis MDP, limitations, and research directions

The relation between PG-MDP and the LLVM-based static-analysis approach is structural. The 2024 work uses LLVM at the IR level, focusing on loops and loop nests. For each load in a loop nest, it checks the load against every store and every call in that nest using LLVM’s dependence analysis, alias analysis, mod/ref analysis, SCEV, and MemorySSA. If LLVM can prove the load cannot depend on any store or call in the loop nest, that load is marked as a PND load, for “predict no dependency” (Panayi et al., 2024).

The two approaches differ primarily in how they identify removable loads. The static-analysis method relies on off-the-shelf LLVM analysis and explicitly does not claim a novel aliasing algorithm. PG-MDP instead relies on profiling store-distance behavior and is intended to capture not only memory-independent loads but also rarely dependent loads, structurally independent loads, and fast-to-resolve dependencies. This suggests that PG-MDP generalizes the earlier bypass idea from proof-based independence to profile-backed effective independence (Panayi et al., 9 Apr 2026).

Both approaches document limitations. The static-analysis method is limited to loop nests, while the CPU does not know about loop boundaries; therefore, a load that is independent inside the loop may still depend on a store earlier in the same function, in a previous loop, or in a caller. The main danger is repeated violations rather than a single violation, as in the example of two loops over the same array where the second loop’s load repeatedly outruns the first loop’s store if both are within the same out-of-order window (Panayi et al., 2024).

PG-MDP identifies a different primary downside: false positives from training/reference mismatch. If a load is labelled as independent during training but becomes dependent on reference inputs, it can cause extra memory-order violations. The paper finds that violations do increase, but they are rare compared to false dependencies, so net performance still improves. It also notes threshold sensitivity, ISA encoding space as a constraint, portability of thresholds across heterogeneous systems, and that the method helps less when the predictor is already large (Panayi et al., 9 Apr 2026).

The broader significance stated across the two papers is that compiler or profile information can offload easy memory dependence questions from hardware predictors. The 2024 work points toward interprocedural analysis, loop versioning, anti-dependence recognition, stack-spill handling, stronger MLIR-based domain-specific analysis, and applying the same idea to more modern predictors like Store Vectors or PHAST. The 2026 work shows that, for area-constrained cores, targeting the predictor working set can deliver performance competitive with large predictors while still using very small predictors (Panayi et al., 2024).