Load-Hit-Store Hazard Prediction in Out-of-Order Processor Cores
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In pipelined processors supporting out-of-order execution, load-hit-store hazards lead to significant resource consumption and performance penalties due to repeated rejection and reissue of load instructions, especially in program loops.
Innovation Solution
A processor core with a load-hit-store detection table that predicts potential hazards by storing address information for store instructions and tagging subsequent load instructions, allowing them to be executed only after the corresponding store operation is completed, thereby reducing rejections and reissues.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If load-hit-store hazard detection is performed in the load-store unit, then hazards are detected, but load instructions are rejected and reissued multiple times consuming resources
Solution Approach 1:
The patent applies preliminary action by performing load-hit-store hazard detection in the instruction dispatch unit before instructions are issued to execution units. The dispatch unit checks the load-hit-store detection table for potential hazards and tags load instructions in advance, preventing rejected reissues later in the pipeline and maintaining high throughput while ensuring reliable hazard detection.
2Reliability
If rejected load instructions are reissued, then correct execution order is maintained, but issue queue space is consumed and resources are wasted
Solution Approach 1:
The dispatch unit performs preliminary hazard detection and tags load instructions before they enter the issue queue. By identifying potential load-hit-store hazards in advance and tagging them with the corresponding store instruction's ITAG, the system prevents incorrect reissues and optimizes issue queue space utilization while maintaining execution correctness.
3Loss of time
If load instructions are tagged with dependency flags, then reissue operations are prevented, but first issue rejection and flushing of newer instructions still occurs
Solution Approach 1:
The patent applies preliminary action by performing hazard detection and tagging at dispatch time rather than waiting for execution. The dispatch unit checks the load-hit-store detection table immediately when decoding instructions, tags load instructions with matching store ITAGs before issuance, and prevents the initial rejection and flushing that would otherwise occur, thereby eliminating time loss without sacrificing productivity.
Data Source
AI summary
A processor core supporting out-of-order execution (OOE) includes load-hit-store (LHS) hazard prediction at the instruction execution phase, reducing load instruction rejections and queue flushes at the dispatch phase. The instruction dispatch unit (IDU) detects likely LHS hazards by generating entries for pending stores in a LHS detection table. The entries in the table contain an address field (generally the immediate field) of the store instruction and the register number of the store. The IDU compares the address field and register number for each load with entries in the table to determine if a likely LHS hazard exists and if an LHS hazard is detected, the load is dispatched to the issue queue of the load-store unit (LSU) with a tag corresponding to the matching store instruction, causing the LSU to dispatch the load only after the corresponding store has been dispatched for execution.