Split Load-Hit-Store Table for Out-of-Order Processor Hazards
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In out-of-order processors, load-hit-store hazards lead to significant performance penalties due to the rejection and reissue of load instructions, causing resource consumption and pipeline flushes, as younger load instructions execute before older store instructions, resulting in stale data and incorrect computations.
Innovation Solution
The implementation of a split load-hit-store (LHS) table, which uses a mod operation to determine the appropriate split table for store instructions, generating an ITAG to manage dependencies and prevent rejections by retaining load instructions in the issue queue until the corresponding store instruction is committed, thereby reducing load rejections and pipeline flushes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a single LHS table is used to track store instructions, then the table coverage is complete, but the access conflict and rejection rate increase when multiple store instructions target the same table
Solution Approach 1:
The single LHS table is divided into multiple split tables (e.g., LHS table 0 and LHS table 1). Store instructions are distributed across these tables using a modulo operation on the instruction tag (ITAG). This segmentation reduces access conflicts because multiple store instructions are likely to be placed in different tables, thereby reducing the rejection rate and improving instruction throughput while maintaining complete coverage through the distributed structure.
2Reliability
If load instructions are rejected due to LHS hazards, then data consistency is maintained, but pipeline flushes and resource consumption increase
Solution Approach 1:
The split LHS tables are populated with store instruction information in advance of load instruction execution. When a load instruction is issued, the processor can proactively check the split LHS tables to determine if a store instruction is pending for the same memory address. This preliminary checking allows the processor to detect potential LHS hazards before they cause incorrect data to be loaded, enabling early handling that avoids pipeline flushes and reduces time loss while maintaining data consistency.
3Reliability
If the LHS table size is increased to reduce rejections, then more store instructions can be tracked, but the hardware area and access time increase
Solution Approach 1:
Instead of using one large LHS table that would require significant hardware area, the system segments the tracking function across multiple smaller tables. Each split table stores information for a subset of store instructions, determined by distributing ITAGs using a modulo operation. This approach achieves the same tracking accuracy as a large table would provide, but with reduced area per table and improved parallel access characteristics, since multiple smaller tables can be accessed simultaneously with less contention.
Data Source
AI summary
According to one or more embodiments, an example computer-implemented method for executing one or more out-of-order instructions by a processing unit, includes decoding an instruction to be executed, and based on a determination that the instruction is a store instruction, identifying a split load-hit-store (LHS) table for the store instruction, wherein a LHS table of the processing unit includes multiple split LHS tables. Identifying the split LHS table includes determining, for the store instruction, a first split LHS table by performing a mod operation using one or more operands from the store instruction, and adding one or more parameters of the store instruction in the first split LHS table by generating an ITAG for the store instruction. The method further includes dispatching the store instruction for execution to an issue queue with the ITAG.


