Reuse of speculative load instruction results from error paths

Abstract

The disclosed technology relates to reuse of speculative results from incorrect execution paths. In some embodiments, when a control transfer instruction is mispredicted, a load instruction may have been executed on an erroneous path. In a disclosed embodiment, a result storage circuit records information indicating a destination register that includes a speculatively executed load instruction of a first load instruction. The control flow tracker circuit may store information indicative of a re-convergence point for the control transfer instruction. The reuse control circuit may track a register written by an instruction prior to the re-rendezvous point, determine that the first load instruction is not dependent on data from any instruction between the control transfer instruction and the re-rendezvous point, and as a result of the first load instruction, reload the first load instruction to the re-rendezvous point. Values from a destination register of a record written based on speculative execution of the first load are used despite misprediction of the control transfer instruction.

Description

Technical Field

[0001] This disclosure relates generally to computer processors, and more specifically to reusing speculative instruction results in the context of mispredicted branches. Background Technology

[0002] Description of related fields Mispreting control transfer instructions (such as branches) is costly for the performance of a computer processor. Typically, instructions on the "wrong" path (the incorrectly predicted path) are flushed, and the processor's front end is redirected to the correct path. This can essentially waste the execution of instructions speculatively executed on the wrong path and delay the execution of instructions on the correct path. Therefore, significant engineering efforts have been devoted to improving the accuracy of branch predictors. However, some data-dependent branches remain very difficult to predict. Attached Figure Description

[0003] Figure 1 This is a diagram illustrating an example processor pipeline based on some implementation schemes.

[0004] Figures 2A to 2D This is a diagram illustrating sample code with control and data-independent regions according to some implementation schemes.

[0005] Figure 3 This is a flowchart illustrating an example reuse technique for control and data-independent instructions according to some implementation schemes.

[0006] Figure 4 This is a block diagram illustrating detailed example reuse logic configured to reuse branches and load results according to some implementation schemes.

[0007] Figures 5A to 5H This is a diagram illustrating an example data structure utilized by reuse logic according to some implementation schemes.

[0008] Figure 6 This is an example based on some implementation schemes. Figure 2A The code example provides a diagram illustrating the instance reuse logic state during execution.

[0009] Figure 7 This is a flowchart illustrating a technique for rapidly updating a live-out mask based on some implementation examples.

[0010] Figure 8 This is a flowchart illustrating an example load value reuse technique based on some implementation schemes.

[0011] Figure 9 This is a flowchart illustrating an example branch direction reuse technique based on some implementation schemes.

[0012] Figure 10 This is a block diagram illustrating detailed example reuse logic configured to reuse branch results according to some implementation schemes.

[0013] Figure 11 This is a block diagram illustrating detailed example reuse logic configured to reuse loading results according to some implementation schemes.

[0014] Figures 12 to 13 This is a flowchart illustrating example methods based on some implementation schemes.

[0015] Figure 14 This is a block diagram illustrating an example computing device based on some implementation schemes.

[0016] Figure 15 These are illustrations illustrating example applications of systems and devices disclosed according to some implementation schemes.

[0017] Figure 16 This is a block diagram of an example computer-readable medium illustrating storage circuit design information according to some implementation schemes. Detailed Implementation

[0018] To mitigate the performance impact of mispredicted control transfer instructions, it may be desirable to reuse some speculative results from instructions executed on the wrong path. This could involve identifying control-independent instructions (e.g., instructions executed regardless of the direction of the control transfer) and data-independent instructions (e.g., instructions that do not depend on data generated by instructions on the bad path). In some implementations, the control circuitry retains and reuses results from such instructions after refreshes and redirections due to misprediction.

[0019] To identify control-independent instructions, it's important to note that different paths from a given control transfer instruction can eventually reconverge at a reconverging point. Instructions on bad paths before the reconverging point are "control-dependent" (CD), while instructions after the reconverging point are "control-independent" (CI). As discussed above, some of these instructions are also "data-independent" (DI), for example, when they do not depend on data from any executed instructions from bad paths. If the results from control-independent and data-independent (CIDI) instructions can be correctly identified (while control-independent but data-dependent (CIDD) instructions need to be executed again), they can be reused (instead of a complete refresh).

[0020] In the disclosed implementation, the circuit is configured to reuse instruction results identified as CIDI (e.g., branch and load results). This may include identifying re-convergence points (after which instructions are control-independent) and tracking data-independent instructions.

[0021] As a detailed example, a Branch Live Output Table (BLOT) may include an entry for each branch, which tracks the re-convergence point of that branch and uses a "live output" mask to track registers written before the re-convergence point. Generally, the live output mask indicates whether the result from a bad path is live output to a control-independent region. When a branch is executed and determined to have been mispredicted, it may flush instructions from the bad path, and some of these instructions may be re-executed on the correct path. In this scenario, the live output mask vector is updated with operand-independent instructions to clear registers written after the re-convergence point (in a control-independent region). Therefore, in some implementations, instructions in the control-independent region are CIDIs and can be reused if all their source registers are cleared in the live output mask.

[0022] Simultaneously, during execution on bad paths, the results of newer speculatively executed instructions (e.g., load values ​​and branch directions) are stored. It should be noted that in various implementations, speculative results are stored during speculative execution before a misprediction of an older branch is detected. If the results of some of those instructions prove to be CIDI after a misprediction, the control circuitry reuses those results after a refresh instead of re-executing the instructions.

[0023] Specifically, in some implementations, the Load Information Table (LIT) and Load Reuse Table (LRT) are configured to store labels for destination physical registers that hold values ​​from a more recent speculatively executed load. In the event of a misprediction, the contents of the Load Information Table after the re-convergence point are copied to the Load Reuse Table. The destination physical registers of the CIDI load in the Load Reuse Table are prevented from being released and are then reassigned to the load as valid physical registers after a refresh (reusing previously determined values ​​in the physical registers instead of re-executing the load). In other implementations, other techniques may be used to retain load values, such as storing the load values ​​themselves in the reuse table.

[0024] As another example, in some implementations, the Branch Information Table (BIT) and Branch Reuse Table (BRT) are configured to store the directions of more recently speculatively executed branches. Reusing branch directions avoids both recalculating the directions and mispredicting for these branches.

[0025] The following section discusses the techniques and circuitry related to: finding re-converging points, fast updates of the live output mask for tracking data correlation, advanced tracking structures that allow for reduction in the size of other structures, and example conditions for reuse, etc.

[0026] In various implementations, one or more predictors are configured to predict the direction and target of control transfer instructions (e.g., branches). It should be noted that throughout this disclosure, the terms "control transfer instruction," "program flow instruction," and "branch instruction" are used interchangeably. Such instructions include at least conditional branch instructions, call instructions, return instructions, jump instructions, etc. Additionally, while the term "branch instruction" or (or more concisely, "branch") may be used throughout this disclosure, it should be understood that the term applies to any type of control transfer instruction that can be utilized in an instruction set architecture.

[0027] Processor Pipeline Overview Now go to Figure 1 The diagram illustrates a block diagram of one embodiment of a processor pipeline 100. In some embodiments, the logic of the processor pipeline 100 is included in one or more cores of a central processing unit (CPU). The processor pipeline 100 includes an instruction fetch unit (IFU) 102. Fetched instructions are passed from the IFU 102 to a mapping / decoding / renaming unit 110 and ultimately to a dispatch unit 120. The dispatch unit 120 is coupled to dispatch instructions to any of a plurality of instruction execution resources, including an execution unit 126 (and potentially other units, such as a load-memory unit (LSU) and / or a floating-point / graphics unit (FGU)). Instruction execution resources may be coupled to a working register file. It should be noted that the illustrated embodiment is merely one example of how the processor pipeline 100 is implemented. In other embodiments, the processor pipeline 100 includes Figure 1 Other components and interfaces not shown. Alternative configurations and variations are possible and envisioned.

[0028] Completion unit 114 includes a reorder buffer (ROB) 116 and coordinates the transfer of speculative results to the architectural state of processor 100. Entries in ROB 116 are assigned in program order. Completion unit 114 includes other elements for disposing of instruction completion / retirement and / or storing history, including register values. In some embodiments, speculative results of instructions are stored in ROB 116 before being committed to the architectural state of processor 100, and confirmed results are committed in program order. When it is permitted to write the results of entries in ROB 116 to the architectural state, these entries are marked as completed. Completion unit 114 also coordinates instruction flushing and / or instruction replay.

[0029] Reordering buffer 116 is coupled to IFU 102, mapping / decoding / renaming unit 110, working register file, and output for any number of instruction execution resources used to support out-of-order instruction execution. In one embodiment, each of instruction cache 104 and data cache is a Level 1 (L1) cache of the cache memory hierarchy subsystem. In such an embodiment, the cache (if present) is a Level 2 (L2) data cache, and the cache controller is a Level 2 (L2) cache controller. In some embodiments, the Level 1 (L1) cache (e.g., instruction cache 104 and L1 data cache, not shown) is at the lowest level in the cache memory hierarchy and is directly connected to processor 100.

[0030] In various implementations, IFU 102 also includes a branch predictor 106 for predicting the outcome of branch instructions to remove control dependencies in the code. In various implementations, IFU 102 also includes a return address stack (not shown). In addition to the data structures shown, IFU 102 includes several data structures such as an instruction translation lookaside buffer (ITLB), an instruction buffer, and / or other structures configured to store state related to thread selection and processing (in multi-threaded implementations of processor 100).

[0031] In some implementations, IFU 102 uses upper-level cache controller 103 to fetch instructions from upper-level instruction cache 104 and buffer them for downstream processing. In response to an instruction cache miss, upper-level cache controller 103 can also request data from lower-level caches or from memory via lower-level cache controller 140. The instructions fetched by IFU 102 in a given clock cycle are referred to as a fetch set, which may include any number of instructions depending on the implementation. In one implementation, mapping / decoding / renaming unit 110 prepares the fetched instructions for further processing, such as by examining the opcode of the fetched instructions, determining register identifiers for the source and destination operands, and performing a register renaming operation.

[0032] The mapping circuit maps the decoded instruction (or uop) to a physical register within processor 100. The mapping unit also implements register renaming to map the source register address from the uop to a source operand number identifying the renamed source register. The dispatch circuit dispatches the uop to a reserved station (not shown) within various execution units. The issuing unit 120 delivers the instruction source and data to the various execution units for selecting (i.e., scheduling or dispatching) instructions. In some embodiments, the issuing unit 120 reads the source operand from an appropriate source, which varies depending on the state of the pipeline.

[0033] In some implementations, processor pipeline 100 includes a working register file that stores instruction results (e.g., integer results, floating-point results, and / or condition signature results) that have not yet been committed to the architectural state and are used as a source for certain operands. Various execution units also maintain architectural integer, floating-point, and condition signature states from which operands may originate. Instructions issued from issuing unit 120 proceed to one or more of the exemplary execution units to be executed. In one implementation, each of execution units 126 is similarly or identically configured to execute certain integer type instructions defined in the implemented ISA, such as arithmetic instructions, logical instructions, and shift instructions.

[0034] In the illustrated example, circuit 110 includes reuse logic 135 and refresh control circuitry 145. In some embodiments, refresh control circuitry 145 is configured to refresh speculatively executed instructions in response to mispredicted control transfer instructions. In some embodiments, refresh control 145 is configured to interact with reuse logic 135 to retain some instruction results from bad paths for potential reuse. For example, refresh control 145 may prevent the release of certain physical registers whose contents can be reused.

[0035] In some implementations, reuse logic 135 implements various structures configured to track speculative execution and determine whether speculative results from bad paths can be reused, for example, when they are control- and data-independent.

[0036] It should be noted that although the reuse logic 135 and refresh control 145 are located in stage 110 in the illustrated example, in other implementations, all or part of the circuit may be implemented in other stages.

[0037] Code examples with control-independent regions Figure 2A This is a diagram illustrating sample code 200 with three blocks. In the illustrated example, block A 210 consists of five instructions and ends with a conditional control transfer instruction (a branch if equal). As shown, there is a misprediction that a branch will be taken, but the correct path actually falls on instruction 6 (the first instruction of block B 220).

[0038] As shown in the figure, the re-convergence point for instruction 5 is instruction 9 (add). Regardless of whether branch instruction 5 is used, the process will eventually reach this point. Instructions between instruction 5 and the re-convergence point are in the control-related region because their execution depends on the result of the corresponding control transfer instruction (instruction 5).

[0039] However, instructions 9 through 14 in block C 230 are in the control-independent region for instruction 5 because they follow the reconvergence point. As shown, the control-independent region includes data-dependent instructions (11 and 12) and data-independent instructions (9, 10, 13, and 14). Instructions 11 and 12 are data-dependent because they depend on the result of instructions in the control-dependent region. Specifically, instruction 11 uses register x6 as its input operand, which is written by instruction 7. Similarly, instruction 12 uses register x13 as its input operand, which is written by instruction 11, which in turn depends on the control-dependent region discussed above.

[0040] In the illustrative code examples discussed in this article, bold register identifiers indicate registers that are written to and will cause data dependencies for any instructions that use that register as input. Underlined register identifiers indicate that their value (directly or indirectly) depends on the input operand registers written to in the control-dependent region.

[0041] In contrast, data-independent instructions do not rely on data generated by control-related regions. If these instructions are correctly identified, their results can be reused. For example, instruction 10 loads a value into register x10, and instruction 14 calculates the branch direction and target (target 2). These values ​​can take advantage of significant processing time, and their reuse can advantageously improve performance, reduce power consumption, or both.

[0042] Figure 2B This is a diagram illustrating example code sample 202 for a "double hammock" program. In this example, there are two separate control-dependent regions corresponding to block B 220 and block D 240. In this example, instructions 12 through 16 are all data dependent on instructions from the control-dependent regions.

[0043] Figure 2C This is a diagram illustrating example loop closure code sample 204. In this example, for instruction 5 branch, block C 230 is a control-independent region, and block A 210 is a control-dependent region. In this example, instructions 8 and 9 are data-independent.

[0044] Figure 2DThis is a diagram illustrating example loading misprediction code sample 206. This example can occur in a context of load address prediction or load value prediction, where instruction 6 is loaded speculatively based on the predicted address or predicted load value. In this example, misprediction means the reconvergence point is instruction 7, and the load itself is a control-dependent region. Instructions 9 and 10 are data-independent in this example. The various techniques discussed in detail herein for reusing values ​​from speculatively executed control-independent and data-independent (CIDI) instructions in the context of control transfer can be similarly used in other misprediction contexts, such as mispredicted loads.

[0045] An overview of reuse techniques and example reuse logic In the following discussion, Figure 3 An overview of reuse technologies is provided. Figures 4 to 5H Detailed example logic and structure are provided for some implementation schemes, and Figure 6 Provided with Figure 2A The code sample corresponds to the example.

[0046] Figure 3 This is a diagram illustrating example methods for reusing data from control-independent and data-independent operations, according to some implementation schemes. Figure 3 The methods shown can be used in conjunction with any of the computer circuits, systems, devices, components, or assemblies disclosed herein. In various embodiments, some of the method elements shown may be executed concurrently in a different order than shown, or may be omitted. Additional method elements may also be executed as needed.

[0047] At 310, in the illustrated implementation, the control circuitry determines the reconvergence point for a given control transfer command. At 320, the control circuitry records the results of completed control-independent commands (which occur after the reconvergence point). Note that these results may or may not be recorded before identifying the reconvergence point.

[0048] At 330, in the illustrated implementation, the control circuitry determines which control-independent instructions are also data-independent. As shown, this includes determining, at 332, the live output for the control-dependent region (e.g., a live output mask indicating a register to be written in that region), and at 334 updating the live output for the control-independent region (e.g., setting an additional field in the live output mask if a CI instruction that depends on a set register writes to an additional register, clearing a field in the live output mask if a data-independent CI instruction overwrites a register with its field in the set live output mask, or both).

[0049] At 340, in the illustrated implementation, the control circuitry reuses one or more values ​​from control-independent and data-independent instructions (e.g., the value recorded at 320). This could, for example, include using speculative load values ​​(e.g., by preventing remapping of the target physical register and assigning that register to a load for replay). As another example, this could include using a branch target or branch direction for a branch instruction executed speculatively. It should be noted that the term “reuse” is used herein to refer to the use of speculative values, such as after a refresh and replay, but is not intended to imply that the value must be used more than once. Rather, “reuse” can be the first actual use of a value in relation to the architectural state of submitting the result to the processor. Reuse means that not all speculative data is refreshed. The term “reuse” also helps to explain that, in a conventional sense, values ​​on an error path would be discarded rather than reused for any subsequent operations.

[0050] At point 350, in the illustrated implementation, the control circuitry detects when the control-independent region ends. At this point, the control circuitry can invalidate one or more stored or trace data structures, for example, to trace other control transfer instructions.

[0051] Figure 4 This is a block diagram illustrating detailed example reuse logic configured to reuse branches and load results according to some implementation schemes.

[0052] In the illustrated example, reuse logic 135 includes reuse control circuitry 410, branch output table (BLOT) circuitry 420, output mask vector (LOM) circuitry 430, re-convergence table (RT) circuitry 440, execution trace circuitry 450, and circuitry for attaching the reuse structure 455.

[0053] In some implementations, reuse control 410 is configured to access and update the structures of various instances based on the currently executing instructions. Generally, reuse control 410 is configured to store the results of speculatively executed instructions, track data correlations, and determine when speculative results from bad paths can be used after a misprediction is detected.

[0054] In some implementations, the branch live output table 420 includes multiple entries configured to store information for control transfer instructions. In some implementations, the reuse control 410 is configured to allocate an entry in the branch live output table 420 in response to the encounter of a conditional control transfer instruction when an available entry exists in the branch live output table 420. In some implementations, only certain categories of control transfer instructions are tracked, such as non-biased conditional branches. Additionally, in some implementations, only branches predicted as not adopted or predicted as adopted and hit in the reconvergence table 440 are tracked in the branch live output table 420.

[0055] For example, various information can be tracked for a given branch in the branch live output table 420, such as the live output mask, the reconvergence program counter (PC), and so on. Figure 4 Indexes in other structures. See below for reference. Figure 5A The detailed fields for entries in branch live output table 420 are discussed. Reuse control 410 can stop updating the live output mask for an entry in response to finding a re-convergence point for that entry in branch live output table 420.

[0056] In some implementations, reuse control 410 is configured to invalidate entries in branch live output table 420 in response to a threshold number of branches being renamed before a re-convergence point is found. Reuse control 410 may also deassign entries in branch live output table 420 when the corresponding branch is completed and its direction is accurately predicted.

[0057] In some implementations, the live output mask vector 430 is configured to track live output information. When a branch with an entry in the branch live output table 420 executes and a misprediction is detected, reuse control 410 is configured to copy the live output mask from the branch live output table 420 into the live output mask vector 430. The live output mask vector 430 can then continue to track live output information to facilitate accurate reuse. In some implementations, the live output mask vector 430 includes a field (e.g., a bit) for each architecture register that indicates whether the architecture register was written by an instruction in a control-dependent region (or by an instruction in a control-independent region that depends on input generated by the control-dependent region).

[0058] In some implementations, re-convergence table 440 is configured to store re-convergence points for branches. Re-convergence table 440 can be labeled based on the PC of a given branch, and entries can store the PC of the re-convergence point for that branch. Re-convergence table 440 can implement a replacement policy (e.g., an LRU policy) to determine when to evict entries when a new entry needs to be allocated and no entries are invalid. Reuse control can read the re-convergence table when allocating branch live output table entries and when a branch is mispredicted. In some implementations, when a re-convergence table miss is found, reuse control assumes the re-convergence PC equals the branch target.

[0059] In some implementations, reuse control 410 is configured to store information associated with PCs (e.g., copied from reorder buffer 116) of instructions on the error path, and then perform CAM against that information after a refresh caused by a misprediction to find a re-convergence point (where a re-convergence point occurs when there is a hit for an instruction with a replay of instructions from a previously executed instruction). In this context, a “CAM” operation refers to determining whether a value exists in content-addressable memory (CAM). In some implementations, utilizing branch information table 470, reuse control 410 is configured to store a range of PCs corresponding to branches in the error path buffer, and perform CAM against those ranges to find re-convergence points. This allows for a much smaller structure for performing CAM compared to checking all PCs. In some implementations, a timeout mechanism may exist to stop the search for a re-convergence point if no re-convergence point is found.

[0060] Furthermore, the reused control 410 can store information on any number of branches / ranges, such as information that may not accurately track reconvergence points and pessimistically mark some control-independent instructions as control-dependent. This can still provide satisfactory performance improvements for certain implementations while reducing the area and power consumption of the control circuitry.

[0061] In the illustrated implementation, the execution tracking circuit 450 includes a Load Information Table (LIT) 460, a Load Reuse Table (LRT) 465, a Branch Information Table (BIT) 470, and a Branch Reuse Table (BRT) 475. Generally, these structures can store speculative values ​​during execution for potential reuse in the event of a mispredicted branch.

[0062] In some implementations, the load information table 460 is configured to store information for speculatively executed loads. In some implementations, this includes the load result value itself. In other implementations, it encodes information identifying the location of the load result value, such as a destination physical register. The load information table 460 may also store execution status information for the load. In some implementations, the load information table 460 is a circular buffer and may be implemented using multiple memory banks.

[0063] In some implementations, reuse control 410 is configured to allocate entries in load information table 460 for a given load during the renaming phase. In some implementations, when load information table 460 is full, reuse control 410 overwrites the oldest entry. When a load retires or is refreshed, reuse control 410 may release entries in load information table 460.

[0064] In some implementations, the load reuse table 465 is configured to store a copy of the information from the load information table 460 for a new load at the proportion convergence point in response to the detection of a false prediction. This can retain load value information even after a refresh and front-end redirection. In some implementations, the load reuse table 465 is also a circular buffer.

[0065] When a load is renamed on the correct path, reuse control 410 can read and deallocate entries in load reuse table 465 in first-in-first-out (FIFO) order. The reuse circuitry can also determine the end of a control-independent region based on the failure to match a renamed load with an entry in load reuse table 465 (which can be marked using a load PC).

[0066] In some implementations, branch information table 470 is configured to store information for branch instructions to be executed speculatively. In some implementations, this includes the direction of the branch instructions to be executed speculatively. In some implementations, branch information table 470 is a circular buffer.

[0067] In some implementations, branch reuse table 475 is configured to store copy information of new branches for the weighting convergence point from branch information table 470 in response to the detection of a misprediction. This can retain branch information even after refresh and frontend redirection.

[0068] When renaming a branch on the correct path, reuse control 410 can read and deallocate entries in branch reuse table 475 in FIFO order. The reuse circuit can also determine the end of the control-independent region and terminate the reuse attempt based on the failure to match the renamed branch with an entry in branch reuse table 475 (which can be marked using branch PC) or the branch reuse table 475 becoming empty.

[0069] In the illustrated implementation, the reuse structure 455 includes storage to a load transfer cloning filter (SBF) 480, a load information table register effective array (LVRA) 485, and a load information table index map (LIM) 490. Generally, these structures can provide additional functionality for properly reusing load results or improving the efficiency of other structures.

[0070] In the illustrated implementation, the store-to-load forwarding cloning filter (SBF) 480 is configured to handle memory dependencies for the load. It should be noted that a load can have both register dependencies and memory dependencies. In the illustrated implementation, the live output table tracks register dependencies but not memory dependencies. Therefore, a store on an undesirable path to the same location as the load may mean that the speculative load value is incorrect.

[0071] In some implementations, reuse control 410 is configured to optimistically allow loading to continue even if storage to the same location exists, but in response to detecting that data retrieved by the load is written to storage in the control-related area, it is configured to set the entry stored in the load forwarding cloning filter (SBF) 480 based on the load's PC (and may refresh the pipeline).

[0072] In some implementations, reuse control 410 is configured not to reuse load values ​​for loads that are hit in the load forwarding cloning filter (SBF) 480. In other implementations, reuse control 410 may check for memory dependencies (e.g., by including memory addresses in the live output mask information) and may not allow load reuse for loads with potential memory dependencies at all.

[0073] In some implementations, the load information table register valid array 485 is configured to track physical registers potentially associated with load reuse and to prevent those registers from being released on flush. Specifically, array 485 may include fields (e.g., bits) for each physical register and may record physical registers written to by loads in entries of load information table 460.

[0074] In some implementations, the load information table index mapping 490 is configured to map indexes in the branch information table 470 to re-aggregate load information table indexes. This can allow for a reduction in the size of the branch reality output table 420, for example, by eliminating the need for entries in table 420 for each branch.

[0075] Figure 5A This is a diagram illustrating example fields of a branch live output table 420 according to some implementation schemes. In the illustrated implementation scheme, table 420 includes a valid field 502, a live output mask 504, a re-convergence program counter (RPC) 506, an RPC found field 508, a re-convergence point LIT index 510, a re-convergence BIT index 512, and a BIT index 514.

[0076] The valid field 502 can indicate whether an entry is valid. The live output mask 504 can include bits for each architecture register and can track registers written on bad paths. Note that the live output mask 504 can be completely cleared when copied to the live output mask vector 430 used for the branch adopted in prediction.

[0077] The re-convergence PC 506 can indicate the program counter for the re-convergence point of the branch corresponding to the entry. The RPC found field 508 can indicate whether a re-convergence point has been found for the branch. As discussed above, if a re-convergence point has not been found after a threshold number of branches have been assigned, the reuse control 410 can invalidate the entry.

[0078] The re-convergence point load information table index 510 indicates the index in the load information table 460 corresponding to the re-convergence point. This allows entries newer than the convergence point in the load information table 460 to be copied to the load reuse table 465 for potential reuse. Similarly, the re-convergence branch information table index 512 can be used to correctly copy entries from the branch information table 470 to the branch reuse table 475.

[0079] In some implementations, branch information table index 514 indicates the index in the branch information table corresponding to the branch itself. When the branch executes and matches its prediction, reuse control 410 can perform CAM on index 514 in table 420 and deallocate the matching entry.

[0080] Figure 5B This is a diagram illustrating an example live output mask vector 430 according to some implementation schemes. In this example, the live output mask vector 430 includes bits of each architecture register as an array 516. In other implementations, other techniques may be used to encode the live output information. As discussed above, the live output mask vector 430 may be initially copied from the branch live output table in case of misprediction and then updated to correctly reflect register dependencies.

[0081] Figure 5C This is a diagram illustrating example fields of table 475 for branch reuse according to some implementation schemes. In the illustrated example, the fields include valid field 520, PC hash 522, direction 524, and direction valid 526.

[0082] The valid field 520 indicates whether the entry is currently valid. The PC hash 522 is a hash of the program counter for the corresponding branch and is used to identify the entry for that branch. The direction 524 indicates the direction of the branch and can be updated once the branch has been speculatively executed. The direction valid field 526 indicates the execution status of the branch (e.g., whether the branch has actually been sufficiently executed to make the direction field valid). In other embodiments, the branch reuse table 475 may include one or more fields associated with the target of a speculatively executed branch (e.g., the target itself, an identifier for the target's storage location, a field indicating whether the target is valid, etc.).

[0083] Figure 5DThis is a diagram illustrating example fields of a re-aggregation table 440 according to some implementation schemes. In the illustrated example, the fields include a valid field 530, a hash PC label 532, a re-aggregation PC 534, and a least recently used (LRU) field 536.

[0084] In this example, the hash PC of a given branch is used as label 532. The re-aggregation PC 534 is the re-aggregation point for a given branch. The LRU field 536 is used to determine which entry to replace when all entries are valid and a new entry is needed.

[0085] In some implementations, reuse control 410 assigns entries in re-convergence table 440 when a re-convergence point is found for a given branch, and performs CAM on the branch PC to populate fields of the branch reality output table entries. In some implementations, reuse control 410 is configured to assign entries in re-convergence table 440 only if the re-convergence point is different from the branch target. If the branch does not find a match in re-convergence table 440, it can be assumed that the re-convergence point is the same as the branch target.

[0086] Figure 5E This is a diagram illustrating example fields of a load information table 460 according to some implementation schemes. In the illustrated example, the fields include valid field 540, PC hash 542, destination physical register tag 544, destination physical register valid 546, reorder buffer (ROB) group number 548, and surround 549.

[0087] Reuse control 410 can assign entries for each load and populate various fields as the load speculatively completes. In the event of a misprediction, reuse control can copy certain fields to the load reuse table 465 (e.g., perform CAM on the PC hash to determine new entries for the specificity convergence point).

[0088] PC hash 542 identifies the load associated with the entry. Destination physical register label 544 indicates the destination physical register of the load. Destination physical register valid field 546 indicates the execution status, such as whether the physical register has been written. ROB group number 548 indicates the reorder buffer group of the load, and around value 549 indicates whether one or more arounds of the circular buffer have occurred. In some implementations, this may allow individual loads to be identified.

[0089] As discussed above, in other implementations, load information table 460 and load reuse table 465 may store the actual load value, or some other encoding of the load value, instead of an identifier of the physical register. However, identifying the physical register can reduce the overall size of these tables, for example, due to the relatively small number of bits used to identify the physical register.

[0090] Figure 5FThis is a diagram illustrating example fields of the load reuse table 465 according to some implementation schemes. In the illustrated implementation scheme, the valid 550, PC hash 552, destination PR label 554, and destination PR valid fields are similar to those in the branch information table 470 and can be copied from the load information table 460 in response to misprediction.

[0091] In some implementations, reuse control 410 is configured to reuse speculatively executed loads by using the destination physical register tag from field 554 and retaining the register value array bits set for that physical register when the PC hash 552 matches the current PC after redirection, field 556 indicates that the destination physical register is valid, the live output mask indicates that the load is data-independent, and there is no hit in the Bloom filter 480.

[0092] If a load-on-reuse table miss is encountered after a refresh and redirection, reuse control 410 can determine that the control-independent region has ended and can release the remaining entries in the load-on-reuse table 465.

[0093] Figure 5G This is a diagram illustrating an example load information table register valid array 485 according to some embodiments. In the illustrated embodiment, array 560 includes bits for each physical register that indicate which physical registers are loaded by load entries in the load information table. These bits can be written as load information table 460 entries are read to populate load reuse table 465. Physical registers not set in array 560 can be returned to the free list, while set registers are prevented from being released, thus allowing potential reuse.

[0094] Figure 5H This is a diagram illustrating example entries in a load information table index mapping 490 according to some implementation schemes. In the illustrated example, a given entry indicates a re-aggregated load information table index for a given branch information table index. In the illustrated example, for each entry in branch information table 470, an entry exists at the same index in LIM 490.

[0095] This avoids the need for branch fact output table entries for each branch. For example, in some implementations, reuse control 410 is configured to populate entries in LIM 490 for branches predicted to be adopted, but only to assign branch fact output table entries for branches not predicted to be adopted. Reuse control 410 can correctly identify the indices in load information table 460 associated with the re-convergence points for branches that do not have entries in the branch fact output table. Note that for those branches predicted to be adopted, information from the branch fact output table may not be needed because no registers will be written on fall-through paths (which are not speculatively executed due to the prediction of adoption), and the fact output mask will be all zeros. In some implementations, this can allow for smaller branch fact output tables, which can reduce circuit area and power consumption.

[0096] In other implementations, the information in LIM 490 can be included as a field in the branch information table 470 entry.

[0097] It should be noted that in other embodiments, circuits 460 and 465 may be combined, circuits 470 and 475 may be combined, or both may be combined (instead of copying from 460 to 465 or from 470 to 475 in case of misprediction). Furthermore, while the illustrated codes are included for illustrative purposes, these illustrated codes are not intended to limit the scope of this disclosure. In other embodiments, various other codes may be used for the illustrated structure. Additionally, while loading and branching are discussed, similar techniques can be used to reuse values ​​from various other types of instructions. Furthermore, the term "instruction" is intended to be interpreted broadly to include various codes encompassing processor operations, including but not limited to API instructions, micro-operations generated based on decoded instructions, etc.

[0098] Live output and reuse examples Figure 6 This is an example based on some implementation schemes. Figure 2A The code example provides a diagram illustrating the instance reuse logic state during execution. Generally, Figure 6 A series of execution points are shown (where relatively earlier events are closer to the top of the graph, and relatively later events are closer to the bottom). The first three rows show the values ​​of the fields in the branch live output table 420 at different execution points, and the last two rows show the values ​​of the live output mask 430 at different execution points.

[0099] As shown in the figure, after the conditional branch instruction 5 is renamed ("beq target 1"), the valid bits of table 420 are set, the real output mask is all zeros, the re-convergence PC is target 1, no re-convergence PC has been encountered, and the branch information table index is six.

[0100] After renaming the instructions in the control-related area (based on the misprediction of the branch not being adopted), the live output mask has been updated to reflect the writes to physical registers x3 and x6.

[0101] Upon reaching the re-convergence point, the RPC is set to find the fields. Additionally, the indexes of Load Information Table 460 and Branch Information Table 470 are populated (in this example, to six and eight, respectively).

[0102] As shown in the figure, a misprediction is detected and a refresh occurs. When a branch is executed, the reuse control 410 uses the branch information table index of the mispredicted branch to perform CAM on the branch live output table, copies the live output mask from table 420 to the live output mask vector 430, and dealslocates entries in table 420.

[0103] The processor is redirected to the correct path (starting at instruction 9), and reuse control 410 appropriately updates the live output mask vector 430. Specifically, after the renaming in instruction 9, reuse control 410 clears the bits for register x3, since that register has been overwritten and no longer depends on data from the control-related region.

[0104] For instruction 10, reuse control 410 can perform CAM on load reuse table 465. If the load is executed speculatively, reuse control 410 can map the previously written physical register identified by field 554 to x10 and avoid re-executing instruction 10.

[0105] As shown in the figure, after the renaming of instruction 11, reuse control 410 has updated the live output mask vector to indicate that x13 corresponds to data dependency (because it is written based on a multiplication operation using register x6 as input, which is written to the control dependency area).

[0106] exist Figure 2A In the example, instruction 14 can also be reused. For example, based on the fact that the x10 and x5 registers being compared do not have the correlation indicated in the real output mask vector 430, if the conditional branch has been speculatively executed, the reuse control can use the PC of instruction 14 to perform CAM on the branch reuse table and use the direction in field 524.

[0107] Example of a fast live output mask update technique Figure 7 This is a flowchart illustrating a fast live output mask update technique based on some implementation examples. Figure 7The methods shown can be used in conjunction with any of the computer circuits, systems, devices, components, or assemblies disclosed herein. In various embodiments, some of the method elements shown may be executed concurrently in a different order than shown, or may be omitted. Additional method elements may also be executed as needed.

[0108] Generally, updating the live output mask should be performed quickly, for example, within a single loop. However, for processors decoding multiple instructions in a decode group, this can be challenging because it requires checking for dependencies associated with other instructions in the same decode group. Therefore, in some implementations, reuse control is configured to update the live output mask using imprecise updates. This technique may be conservative in the sense of sometimes flagging incorrect dependencies, but it ensures that no dependencies are missed and allows for rapid updates to the live output mask.

[0109] exist Figure 7 In the example, the processor supports decoding groups with up to P instructions (where P is an integer) and includes P decoding channels. For example, the disclosed operations can be performed in the renaming pipeline stage.

[0110] At 710, before reaching the reconvergence point, the control circuit sets bits in the fact-out mask for the destination register written by the instruction (potentially on a bad path if the branch is predicted not to be adopted but is actually adopted).

[0111] At 720, the control circuitry determines whether the reconvergence point has been reached. If not, the process returns to 710. If yes, the process proceeds to 730 and 750. In this example, the process runs in parallel for the first M decoding channels at elements 730 and 740, and in parallel for the remaining decoding channels from 750 to 770.

[0112] At 730, in the illustrated example, the control circuitry sets the LOM (Location Output Mask) bits of the destination register for instructions that have any source bits set in the LOM. In other words, if an instruction has an input operand whose bits are set in the LOM, the LOM bits of the destination register for that instruction are set.

[0113] At 740, in the illustrated example, the control circuitry clears the bits in the destination register for instructions for which the source bit was not set in the actual output mask. Because these instructions do not depend on data from bad paths, their overwriting of the destination register means that the destination register is no longer data-dependent. Note that for a given instruction, at most one of the operations in elements 730 or 740 can be performed.

[0114] The operations of elements 730 and 740 are performed sequentially for the first M decoded channels (e.g., starting with channel 0, then channel 1, then channel 2, and so on). Therefore, when an operation occurs for the second decoded channel, the live output mask has already been updated based on the first decoded channel, and so on (where earlier decoded channels correspond to older instructions).

[0115] At 750, in the illustrated example, for a given channel N in the remaining decoding channels, the control circuitry assumes that the live output mask bits of the destination register are set for instructions from the previous channels 0 to NM (this corresponds to assuming those instructions are data-dependent). This means that channel N does not need to wait for results from those earlier channels, thus reducing the critical path for live output mask calculation, but potentially introducing false positive dependencies.

[0116] At 760, the control circuitry sets the real-time output mask bits in the destination register for instructions with any source bits set in the real-time output mask. At 770, the control circuitry clears the bits in the destination register for instructions without source bits set in the real-time output mask. As discussed above, the real-time output masks for elements 760 and 770 are simulated based on the previous assumption that channels 0 to NM are data-dependent.

[0117] At 780, the control circuit determines whether the end of the control-independent region has been reached. If so, instruction reuse for the mispredicted branch can end. If not, the flow returns to 730 and 750.

[0118] Return to reference Figure 2A In the code example, if M equals 4, then the last two instructions 13 and 14 will use... Figure 7 The technology is conservatively labeled as data-related.

[0119] However, it should be noted that in other implementations, the live output mask is updated to accurately reflect the correlation. For example, in some implementations, this can be done sequentially for all decoding channels. Figure 7 Elements 730 and 740 can be omitted, and elements 750 through 770 can be omitted to provide accurate live output mask updates.

[0120] Example conditions for the results of usage instructions from bad paths. Figure 8This is a flowchart illustrating an example load value reuse technique according to some implementation schemes. At 810, in the illustrated example, the control circuitry receives a load instruction for renaming (e.g., after a refresh due to misprediction, so that the result information for the load might be stored in the load reuse table 465). The control circuitry determines whether the hash of the loaded program counter matches an entry in the load reuse table. If not, the process proceeds to 860, exits the control-independent region, and the control circuitry deallocates the remaining load reuse table entries.

[0121] If the hash of the program counter matches an entry in the load reuse table 465, the process proceeds to 820, and the control circuitry checks if the destination physical register is valid (e.g., based on field 556). If not, the process proceeds to 870, and the processor re-executes the load. If yes, the process advances to 830. At 830, the control circuitry checks if the live output mask indicates data independence (e.g., whether the source register for the load is cleared in the live output mask). If no, the process proceeds to 870; otherwise, the process proceeds to 840.

[0122] At 840, the control circuitry checks for a hit in Bloom filter 480. If a hit is found, the process proceeds to 870; otherwise, it proceeds to 850. At 850, the control circuitry reuses information from the load. Specifically, the control circuitry uses the same destination physical register label for the rename operation and retains the valid array of registers set for that register. This allows the load to complete (and any newer instructions depending on the result of the load) without re-executing the load.

[0123] Note that this is for reuse. Figure 8 The conditions for loading information are included for illustrative purposes and are not intended to limit the scope of this disclosure. In other embodiments, the illustrated conditions may be omitted, additional conditions may be considered, conditions may be considered based on various logical combinations rather than the illustrated logical AND of the conditions at elements 810-840, and so on.

[0124] Figure 9 This is a flowchart illustrating an example branch direction reuse technique according to some implementation schemes. At 910, in the illustrated example, the control circuitry receives a branch instruction for renaming (e.g., after a refresh due to a misprediction, so that the result information for the branch might be stored in the branch reuse table 475). The control circuitry determines whether the hash of the branch's program counter matches an entry in the branch reuse table 475. If not, the process proceeds to 960, exits the control-independent region, and the control circuitry deallocates the remaining branch reuse table entries and loads reuse table entries. This can correspond to the termination of control-independent drive reuse for that particular misprediction.

[0125] If the hash of the program counter matches an entry in the branch reuse table 475, the process proceeds to 920, and the control circuitry determines whether the direction for the branch is valid (e.g., based on field 526). If not, the process proceeds to 970, and the processor does not reuse information from the previous execution of the branch (instead, it can use the current branch prediction from the branch predictor and eventually complete and commit the branch). Otherwise, the process proceeds to 930.

[0126] At 930, the control circuitry determines whether the live output mask indicates data independence. If not, the process proceeds to 970; otherwise, it proceeds to 940. At 940, the control circuitry determines whether the direction differs from the branch prediction for the branch. If not, the process proceeds to 970 (no further reuse action is required if the reused information matches the prediction). Otherwise, the process proceeds to 950, and the control circuitry reuses information from the previously executed branch. In this case, the control circuitry indicates a misprediction and redirects the processor front-end (e.g., because the reused direction indicates the predicted direction is incorrect).

[0127] As discussed above, in some implementations, the target of the branch can also be saved and can be used for redirection at point 950.

[0128] Note that this is for reuse. Figure 9 The conditions for the branch information are included for illustrative purposes, but are not intended to limit the scope of this disclosure. In other embodiments, the illustrated conditions may be omitted, additional conditions may be considered, conditions may be considered based on various logical combinations rather than the illustrated logical AND of the conditions at elements 910-940, and so on.

[0129] Example implementations with only load reuse or only branch reuse. Figure 10 This is a block diagram illustrating an example of reuse logic 135 that implements branch reuse but not load reuse. Figure 11 This is a block diagram illustrating an example of reuse logic 135 that implements load reuse but not branch reuse. Figure 10 and Figure 11 The elements can be referenced as above. Figure 4 The configuration as discussed. Furthermore, in some implementations, Figure 11The specific implementation demonstrates that the disclosed load reuse technique can operate without elements 480, 485, and 490. While branching or load reuse can be omitted, it should be noted that leveraging both can advantageously have synergistic effects, for example, by sharing structures such as the live output table and the re-aggregation table. Additionally, in some implementations, results from undesirable paths for other types of instructions can also be reused. Generally, reusing instructions whose results utilize significant processing resources for computation may be most beneficial.

[0130] Example Method Figure 12 This is a flowchart illustrating example methods for loading reuse according to some implementation schemes. Figure 12 The methods shown can be used in conjunction with any of the computer circuits, systems, devices, components, or assemblies disclosed herein. In various embodiments, some of the method elements shown may be executed concurrently in a different order than shown, or may be omitted. Additional method elements may also be executed as needed.

[0131] At 1210, in the illustrated implementation, the processor speculatively executes instructions based on the predicted direction of the control transfer instructions.

[0132] At 1220, in the illustrated implementation, the processor records (e.g., in load information table 460, load reuse table 465, or both) information indicating the destination register of a load instruction that is speculatively executed, including the first load instruction.

[0133] In some implementations, the result storage circuitry is configured to record information indicating the destination physical register of a load instruction that is speculatively executed. Reuse control circuitry can prevent the release of the first physical register, as indicated by the result storage circuitry to store the value for the first load instruction, and the use of the value from the first physical register for the first load. Load information table register valid array circuitry (e.g., circuit 485) can indicate the set of physical registers storing values ​​for potential reuse (this prevents those registers from being released during flushing).

[0134] At 1230, in an exemplary embodiment, the processor stores (e.g., in a control flow tracker circuit such as branch live output table 420, reconvergence table 440, or both) information indicating a reconvergence point for a control transfer instruction. In some embodiments, the control flow tracker circuit stores the location corresponding to the reconvergence point in a result storage circuit for the control transfer instruction (e.g., in field 510 of branch live output table 420).

[0135] At 1240, in the illustrated implementation, the processor (e.g., reuse control 410) tracks registers written by instructions prior to the re-convergence point (e.g., using the live output field discussed above).

[0136] At 1250, in the illustrated implementation, in response to a misprediction by the prediction circuitry of a control transfer instruction, the processor executes elements 1260 and 1270. Note that due to the misprediction, a refresh may occur, and the first load instruction may ultimately be replayed. Elements 1260 and 1270 may correspond to the replay of the first load instruction.

[0137] In some implementations, in response to a misprediction, the reuse control circuit copies entries for instructions following the re-convergence point from the result storage circuit to the reuse storage circuit (e.g., from loading information table 460 to loading reuse table 465).

[0138] At 1260, in the illustrated implementation, the processor determines, based on the tracked registers, that the first load instruction is independent of data from any instructions between the control transfer instruction and the re-convergence point. Therefore, the first load instruction is data-independent. The first load instruction can also be control-independent based on its relationship to the re-convergence point and mispredicted direction. In this example, the first load instruction is also control-independent.

[0139] In some implementations, to determine that the first load instruction does not depend on data from any instructions between the control transfer instruction and the re-convergence point, the reuse control circuitry tracks registers written by instructions after the re-convergence point that do not use source data from registers written by instructions before the re-convergence point. For example, the control flow tracker circuitry may include a live output mask field that includes a corresponding indicator for each architecture register in a set of architecture registers supported by the device. The reuse control circuitry may set the indicator in the live output mask field in response to a write to the corresponding architecture register by an instruction between the control transfer instruction and the re-convergence point, and may clear the indicator in the live output mask field in response to a write to the corresponding architecture register by an instruction after the re-convergence point that does not depend on any instructions between the control transfer instruction and the re-convergence point.

[0140] At 1270, in the illustrated implementation, as a result of the first load instruction, the processor uses the value of the destination register of the record written from speculative execution based on the first load. In this example, this use is in response to a determination that the first load instruction is data-independent (and may also be based on a determination that the first load instruction is control-independent), and is executed despite the possibility of a misprediction of a control transfer instruction. Therefore, in this example, the speculative result of the first load instruction from a bad path is reused.

[0141] In some implementations, the reuse control circuitry compares the hash of the program counter with the tag field of the reuse memory circuitry entry to determine the identity of the destination register. For example, the reuse control circuitry may map the hash CAM of the PC of the first load instruction to field 552 of the load reuse table 465.

[0142] In some implementations, the reuse control circuitry is configured to further use the value from the destination register based on a comparison and determination that the destination register is valid, the comparison being based on the program counter of the first load during the re-execution of the first load and the field of the entry in the result storage circuitry for the first load.

[0143] In some implementations, filter circuitry (e.g., circuit 480) prevents the reuse of load instruction values ​​based on incorrect reuse of values ​​for load instructions caused by the results of forwarded store instructions. In some implementations, index mapping circuitry (e.g., circuit 490) maps entries in the control flow tracker circuitry to entries in the result storage circuitry.

[0144] Figure 13 This is a flowchart illustrating example methods for branch reuse based on some implementation schemes. Figure 13 The methods shown can be used in conjunction with any of the computer circuits, systems, devices, components, or assemblies disclosed herein. In various embodiments, some of the method elements shown may be executed concurrently in a different order than shown, or may be omitted. Additional method elements may also be executed as needed.

[0145] At 1310, in the illustrated implementation, the processor speculatively executes instructions based on the predicted direction of the first control transfer instruction.

[0146] At 1320, in the illustrated implementation, the processor records information indicating a determined direction for the speculative execution of a second control transfer instruction that is newer than the first control transfer instruction (e.g., in branch information table 470, branch reuse table 475, or both).

[0147] At 1330, in the illustrated implementation, the processor stores (e.g., in branch live output table 420, reconvergence table 440, or both) information indicating the reconvergence point for the first control transfer instruction.

[0148] In some implementations, to determine the reconvergence point, the control circuit stores multiple instruction address ranges corresponding to the instructions executed between control transfer instructions, and during instruction replay following a misprediction, determines the reconvergence point based on a match between the current program counter and one of the instruction ranges. In some implementations, the control circuitry is reused to populate fields indicating the reconvergence point and fields indicating that the reconvergence point has been found in the control flow tracker circuitry.

[0149] At 1340, in the illustrated implementation, the processor (e.g., reuse control 410 in the live output mask field) tracks registers written by instructions preceding the re-convergence point. In some implementations, the control flow tracker circuitry includes a live output mask field that includes a corresponding indicator for each architecture register in a set of architecture registers supported by the processor. In some implementations, the reuse control circuitry is configured to: set the indicator in the live output mask field in response to a write to the corresponding architecture register by an instruction between the first control transfer instruction and the re-convergence point; clear the indicator in the live output mask field in response to a write to the corresponding architecture register by an instruction after the re-convergence point that does not depend on any instruction between the first control transfer instruction and the re-convergence point; and determine, based on the fact that one or more indicators in the live output mask field are cleared, that a second control transfer instruction does not depend on data from any instruction between the first control transfer instruction and the re-convergence point, the one or more indicators corresponding to one or more input operands of the second control transfer instruction.

[0150] In some implementations, the processor front-end circuitry is configured to decode multiple instructions in a given loop, and the reuse control circuitry is configured to set the live output mask field bits for the target of one or more other instructions decoded in the given loop, assuming the target is one or more other instructions decoded in the given loop, for one or more of the multiple instructions decoded in the given loop. In some implementations, this can provide fast live output mask updates. In some implementations, the reuse control circuitry copies the live output mask field to the reuse memory circuitry in response to misprediction. In some implementations, the reuse control circuitry copies entries for instructions following the re-convergence point from the result memory circuitry to the reuse memory circuitry in response to misprediction.

[0151] At 1350, in the illustrated implementation, in response to a misprediction by the prediction circuit for the first control transfer instruction, the processor executes elements 1360 and 1370.

[0152] At 1360, in the illustrated implementation, the processor determines, based on the tracked registers, that the second control transfer instruction does not depend on data from any instructions between the first control transfer instruction and the reconvergence point.

[0153] At 1370, in the illustrated implementation, the processor responds to the determination by using the recorded determined direction for the second control transfer instruction, despite a misprediction of the first control transfer instruction. This use may include initiating a mispredicted redirection to redirect the front-end circuitry for fetching based on the determined direction.

[0154] In some implementations, the reuse control circuitry also responds to the determination of the determined destination for the second control transfer instruction from the result storage circuitry. In some implementations, after the second control transfer instruction is refreshed and replayed, the recorded determined direction is used for the second control transfer instruction, wherein the device is configured to redetermine the direction for the second control transfer instruction without based on the recorded determined direction usage.

[0155] In some implementations, the use of the recorded determined direction is conditional upon: a comparison of the program counter of the second control transfer instruction with the field of the entry in the result storage circuit for the second control transfer instruction upon re-execution; a determination that the determined direction is valid; and a determination that the determined direction differs from the direction predicted by the prediction circuit for the second control transfer instruction.

[0156] The disclosed techniques can also be used for incorrect speculatively executed load operations (e.g., incorrectly predicted load addresses or values). In some embodiments, the reuse control circuitry is configured to use a predicted direction for a third control transfer instruction that is speculatively executed following an incorrectly executed load operation.

[0157] The concept of “execution” is broad and can refer to 1) the processing of instructions throughout the entire execution pipeline (e.g., through the fetch, decode, execute, and retirement stages), and 2) the processing of instructions at an execution unit or execution subsystem of such a pipeline (e.g., an integer execution unit or a load-memory unit). The latter meaning can also be referred to as a “perform” instruction. Thus, a “perform” summation instruction refers to summing two operands to produce a result, which in some implementations can be achieved by circuitry at the execution stage of the pipeline (e.g., an execution unit). Conversely, an “execute” summation instruction can refer to the entire operation that occurs throughout the pipeline as a result of a summation instruction. Similarly, a “perform” load instruction can include (e.g., retrieving a value from a cache, memory, or the stored result of another instruction) and storing the retrieved value in a register or other location.

[0158] As used herein, in the context of instructions, the term "completion" refers to the submission of the result of an instruction to the architectural state of the processor or processing element. For example, the completion of an addition instruction includes writing the result of the addition instruction to the destination register. Similarly, the completion of a load instruction includes writing a value (e.g., a value retrieved from a cache or memory) to the destination register or its representation.

[0159] The concept of a processor "pipeline" is well-known and refers to the division of the "work" a processor does on instructions into multiple stages. In some implementations, instruction decoding, dispatching, execution (i.e., performing), and retirement can be examples of different pipeline stages. Many different pipeline architectures may have different element / part orders. Various pipeline stages perform these steps on instructions during one or more processor clock cycles, then pass the instruction or the operation associated with the instruction to other stages for further processing.

[0160] For a given program or part of a program, the flow is typically sequential. Consider the following instruction set: ldmem1→r1; add r1, r2→r3; st r3→mem2. In this exemplary sequence, execution and completion proceed sequentially from the load instruction to the add instruction to the store instruction. This sequential ordering can be considered the default for program flow. In this example, none of these instructions influences the selection of the next instruction to be executed and completed (beyond the default behavior).

[0161] In contrast, the execution and completion of instructions with certain opcodes can influence the selection of the next instruction to be executed and completed. These instructions are referred to herein as "control transfer instructions." Control transfer instructions can include, but are not limited to, branches, jumps, calls, and returns. These types of instructions can cause changes to the default behavior of the next instruction to be executed and completed. Control transfer instructions can be used, for example, to execute instruction loops.

[0162] There can also be many different types of control transfer instructions. For example, control transfer instructions can operate conditionally (i.e., set the program counter based on whether a certain condition is true or false) or unconditionally. Similarly, some control transfer instructions can specify a direct target address; others can specify an indirect target address. It should be noted that the execution and completion of control transfer instructions may affect the processor state rather than the location of the next instruction (e.g., there may be instructions that branch after performing arithmetic operations).

[0163] As used herein, the terms “clock” and “clock signal” refer to periodic signals, such as those in binary (binary) electrical signals. A clock changes periodically between “levels” (such as the voltage range of an electrical signal). For example, a voltage greater than 0.7 volts can be used to represent one clock level, and a voltage less than 0.3 volts can be used to represent another level in a binary configuration. As used herein, the term “clock edge” refers to a change in the clock signal from one level to another. As used herein, in the context of clock signals, the term “switch” refers to changing the value of a clock signal from one level to another in a binary clock configuration. As used herein, the term “clock pulse” refers to the interval between consecutive edges of a clock signal (e.g., the interval between a rising edge and a falling edge, or the interval between a falling edge and a rising edge). Note that sequential circuitry can operate on the rising edge of a clock signal, the falling edge of a clock signal, or both (which may be referred to as double-edge triggering).

[0164] Example device Now for reference Figure 14 A block diagram illustrating an example embodiment of device 1400 is shown. In some embodiments, the components of device 1400 may be included within a system-on-a-chip. In some embodiments, device 1400 may be included in a mobile device that may be battery-powered. Therefore, the power consumption of device 1400 may be an important design consideration. In the illustrated embodiment, device 1400 includes configuration 1410, computing complex 1420, input / output (I / O) bridge 1450, cache / memory controller 1445, graphics unit 1475, and display unit 1465. In some embodiments, in addition to or in lieu of the illustrated components, device 1400 may include other components (not shown), such as video processor encoders and decoders, image processing or recognition elements, computer vision elements, etc.

[0165] Architecture 1410 may include various interconnects, buses, MUXs, controllers, etc., and may be configured to facilitate communication between various components of device 1400. In some embodiments, portions of architecture 1410 may be configured to implement various different communication protocols. In other embodiments, architecture 1410 may implement a single communication protocol, and components coupled to architecture 1410 may internally switch from a single communication protocol to other communication protocols.

[0166] In the illustrated implementation, computing complex 1420 includes a bus interface unit (BIU) 1425, a cache 1430, and cores 1435 and 1440. In various implementations, computing complex 1420 may include a variety of numbers of processors, processor cores, and caches. For example, computing complex 1420 may include one, two, four, or any other suitable number of processor cores. In one implementation, cache 1430 is a set-associative L2 cache. In some implementations, cores 1435 and 1440 may include internal instruction and data caches. In some implementations, a coherence unit (not shown) elsewhere in architecture 1410, cache 1430, or other parts of device 1400 may be configured to maintain coherence between the various caches of device 1400. BIU 1425 may be configured to manage communication between computing complex 1420 and other elements of device 1400. Processor cores (such as core 1435 and core 1440) can be configured to execute instructions of a specific instruction set architecture (ISA) that may include operating system instructions and user application instructions.

[0167] In some implementations, the disclosed reuse techniques can advantageously improve the performance of the computational complex 1420, for example, by mitigating the negative impact of mispredictions of control transfer instructions.

[0168] The cache / memory controller 1445 can be configured to manage data transfer between the architecture 1410 and one or more caches and memories. For example, the cache / memory controller 1445 may be coupled to an L3 cache, which in turn may be coupled to system memory. In other embodiments, the cache / memory controller 1445 may be directly coupled to memory. In some embodiments, the cache / memory controller 1445 may include one or more internal caches.

[0169] As used herein, the term "coupled to" can indicate one or more connections between elements, and coupling can include intermediate elements. For example, in Figure 14 In this context, the graphics unit 1475 can be described as being "coupled" to memory via configuration 1410 and cache / memory controller 1445. In contrast, in... Figure 14 In the exemplary implementation, the graphics unit 1475 is "directly coupled" to the configuration 1410 because there are no intermediate elements.

[0170] The graphics unit 1475 may include one or more processors, such as one or more graphics processing units (GPUs). For example, the graphics unit 1475 may receive graphics-oriented instructions, such as OpenGL. ® Metal or Direct3D ®Instructions. The graphics unit 1475 can execute dedicated GPU instructions or perform other operations based on received graphics-oriented instructions. The graphics unit 1475 is typically configured to process large blocks of data in parallel and can build an image in a frame buffer for output to a display, which may be included in a device or may be a separate device. The graphics unit 1475 may include transformation, lighting, triangle, and rendering engines in one or more graphics processing pipelines. The graphics unit 1475 may output pixel information for displaying the image. In various embodiments, the graphics unit 1475 may include programmable shader circuitry, which may include highly parallel execution cores configured to execute graphics programs, which may include pixel tasks, vertex tasks, and computation tasks (which may be graphics-dependent or may not be graphics-dependent).

[0171] It should be noted that in some implementations, the disclosed reuse techniques can also be used in graphics units and other dedicated processors.

[0172] Display unit 1465 may be configured to read data from a frame buffer and provide a stream of pixel values ​​for display. In some embodiments, display unit 1465 may be configured as a display pipeline. Additionally, display unit 1465 may be configured to blend multiple frames to produce an output frame. Furthermore, display unit 1465 may include one or more interfaces (e.g., MIPI) for coupling to a user display (e.g., a touchscreen or an external display). ® Or embedded display port (eDP)).

[0173] I / O bridge 1450 may include various components configured to implement functionalities such as Universal Serial Bus (USB) communication, security, audio, and low-power always-on connectivity. I / O bridge 1450 may also include interfaces such as pulse-width modulation (PWM), general-purpose input / output (GPIO), serial peripheral interface (SPI), and internal integrated circuit (I2C). Various types of peripheral devices and equipment can be coupled to device 1400 via I / O bridge 1450.

[0174] In some embodiments, device 1400 includes network interface circuitry (not explicitly shown) that can be connected to configuration 1410 or I / O bridge 1450. This network interface circuitry can be configured to communicate via various networks, which may be wired networks, wireless networks, or both. For example, the network interface circuitry can be configured to communicate via a wired local area network (LAN), a wireless LAN (e.g., via WiFi), or a wide area network (e.g., the Internet or a virtual private network). In some embodiments, the network interface circuitry is configured to communicate via one or more cellular networks using one or more radio access technologies. In some embodiments, the network interface circuitry is configured to communicate using device-to-device communication (e.g., Bluetooth or WiFi Direct). In various embodiments, the network interface circuitry can provide device 1400 with connectivity to various types of other devices and networks.

[0175] Example Application Now go to Figure 15 This illustrates various types of systems that may include any of the circuits, devices, or systems discussed above. The system or device 1500, which may utilize one or more of the techniques described herein in combination or otherwise, can be used in a wide range of fields. For example, the system or device 1500 can be used as part of the hardware of a system such as a desktop computer 1510, a laptop computer 1520, a tablet computer 1530, a cellular or mobile phone 1540, or a television 1550 (or a set-top box coupled to a television).

[0176] Similarly, the disclosed components can be used in wearable devices 1560, such as smartwatches or health monitoring devices. In many embodiments, a smartwatch can perform a variety of different functions—for example, access to email, cellular services, calendars, health monitoring, etc. Wearable devices can also be designed to perform only health monitoring functions, such as monitoring a user's vital signs, performing epidemiological functions such as contact tracing, providing communication to emergency medical services, etc. Other types of devices are also envisioned, including devices worn around the neck, implantable devices, and glasses or helmets designed to provide computer-generated reality experiences, such as those based on augmented reality and / or virtual reality.

[0177] System or device 1500 can also be used in a variety of other contexts. For example, system or device 1500 can be used in the context of a server computer system (such as a dedicated server) or on shared hardware implementing cloud-based services 1570. Furthermore, system or device 1500 can be implemented in a wide range of dedicated everyday devices, including common household devices 1580 such as refrigerators, thermostats, security cameras, etc. The interconnection of such devices is often referred to as the “Internet of Things” (IoT). Components can also be implemented in various modes of transportation. For example, system or device 1500 can be used in control systems, guidance systems, entertainment systems, etc., of various types of vehicles 1590.

[0178] Figure 15 The applications illustrated herein are merely exemplary and are not intended to limit the potential future applications of the disclosed systems or devices. Other example applications include, but are not limited to, portable gaming devices, music players, data storage devices, drones, etc.

[0179] Example computer-readable media Various example circuits have been described in detail above in this disclosure. It is intended that this disclosure cover not only embodiments including such circuits, but also computer-readable storage media that include design information specifying such circuits. Therefore, this disclosure is intended to support claims that cover not only devices including the disclosed circuits, but also storage media specifying circuits in a format recognized by a manufacturing system configured to produce hardware (e.g., integrated circuits) including the disclosed circuits. Claims regarding such storage media are intended to cover entities that, for example, generate circuit designs but do not manufacture the designs themselves.

[0180] Figure 16 This is a block diagram illustrating an example non-transitory computer-readable storage medium for storing circuit design information according to some embodiments. In the illustrated embodiment, a semiconductor manufacturing system 1620 is configured to process design information 1615 stored on a non-transitory computer-readable medium 1610 and to manufacture an integrated circuit 1630 based on the design information 1615.

[0181] Non-transitory computer-readable storage medium 1610 may include any of a variety of suitable types of memory devices or storage devices. Non-transitory computer-readable storage medium 1610 may be installation media, such as CD-ROM, floppy disk, or magnetic tape devices; computer system memory or random access memory, such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory, such as flash memory; magnetic media, such as hard disk drives or optical storage devices; registers, or other similar types of memory elements, etc. Non-transitory computer-readable storage medium 1610 may also include other types of non-transitory memory or combinations thereof. Non-transitory computer-readable storage medium 1610 may include two or more memory media that may reside in different locations (e.g., different computer systems connected via a network).

[0182] Design information 1615 can be specified using any of a variety of suitable computer languages, including hardware description languages ​​such as, but not limited to, VHDL, Verilog, SystemC, SystemVerilog, RHDL, M, MyHDL, etc. Design information 1615 can be used by semiconductor manufacturing system 1620 to manufacture at least a portion of integrated circuit 1630. The format of design information 1615 can be recognized by at least one semiconductor manufacturing system 1620. In some embodiments, design information 1615 may also include one or more cell libraries specifying the synthesis, layout, or both of integrated circuit 1630. In some embodiments, design information is specified, wholly or partially, in the form of a netlist specifying cell library elements and their connectivity. Design information 1615 acquired alone may or may not include sufficient information for manufacturing the corresponding integrated circuit. For example, design information 1615 may specify circuit elements to be manufactured but not their physical layout. In this case, design information 1615 may need to be combined with layout information to actually manufacture the specified circuit.

[0183] In various implementations, integrated circuit 1630 may include one or more custom macrocells, such as memory and analog or mixed-signal circuitry. In this case, design information 1615 may include information associated with the included macrocells. Such information may include, but is not limited to, schematic capture databases, mask design data, behavioral models, and device or transistor-level netlists. As used herein, mask design data may be formatted according to a Graphical Data System (GDSII) or any other suitable format.

[0184] The semiconductor manufacturing system 1620 may include any of the various suitable elements configured to manufacture integrated circuits. This may include, for example, elements for depositing semiconductor material (e.g., on a wafer that may include a mask), removing material, changing the shape of the deposited material, modifying the material (e.g., by doping the material or by using ultraviolet treatment to modify the dielectric constant), etc. The semiconductor manufacturing system 1620 may also be configured to perform various tests on the manufactured circuits for proper operation.

[0185] In various embodiments, integrated circuit 1630 is configured to operate according to a circuit design specified by design information 1615, which may include performing any of the functionalities described herein. For example, integrated circuit 1630 may include Figure 1 , Figure 4 , Figure 10 , Figure 11 and Figure 13 Any of the various components shown herein. Additionally, integrated circuit 1630 can be configured to perform the various functions described herein in conjunction with other components. Furthermore, the functionality described herein can be performed by multiple interconnected integrated circuits.

[0186] As used herein, a phrase in the form of “design information specifying the design of a circuit configured to…” does not imply that the circuit in question must be manufactured in order to satisfy this element. Rather, the phrase indicates that the design information describes a circuit that, when manufactured, will be configured to perform the indicated action or will include the specified components.

[0187] The various techniques described herein can be executed by one or more computer programs. The term "program" will be broadly interpreted to encompass a sequence of instructions in a programming language executable by a computing device. These programs can be written in any suitable computer language, including lower-level languages ​​such as assembly and higher-level languages ​​such as Python. The program can be written in a compiled language such as C or C++ or an interpreted language such as JavaScript.

[0188] Program instructions may be stored on a “computer-readable storage medium” or “computer-readable medium” to facilitate execution of the program instructions by a computer system. Generally, these phrases include any tangible or non-transitory storage medium or memory medium. The terms “tangible” and “non-transitory” are intended to exclude the propagation of electromagnetic signals, but do not otherwise limit the type of storage medium. Therefore, the phrase “computer-readable storage medium” or “computer-readable medium” is intended to cover types of storage devices that do not necessarily store information permanently (e.g., random access memory (RAM)). Thus, the term “non-transitory” is a limitation on the nature of the medium itself (i.e., the medium cannot be a signal), which contrasts with limitations on the persistence of data storage in media (e.g., RAM and ROM).

[0189] The phrases “computer-readable storage medium” and “computer-readable medium” are intended to refer to storage media within a computer system as well as removable media such as CD-ROMs, Memory Sticks, or portable hard disk drives. These phrases encompass any type of volatile memory within a computer system, including DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc., as well as non-volatile memory such as magnetic media (e.g., hard disk drives) or optical storage devices. These phrases are explicitly intended to cover the memory of servers that facilitate the download of program instructions, the memory within any intermediate computer systems involved in the download, and the memory of all destination computing devices. Furthermore, these phrases are intended to cover combinations of different types of memory.

[0190] Furthermore, a computer-readable medium or storage medium may reside in a first set of one or more computer systems in which a program is executed, and in a second set of one or more computer systems connected to the first set via a network. In a later example, the second set of computer systems may provide program instructions to the first set of computer systems for execution. In short, the phrases "computer-readable storage medium" and "computer-readable medium" can include two or more media that may reside in different locations (e.g., in different computers connected via a network).

[0191] This disclosure includes references to “implementation” or groups of “implementation” (e.g., “some implementations” or “various implementations”). An implementation is a different specific implementation or instance of the disclosed concepts. References to “implementation,” “an implementation,” and “a particular implementation,” etc., do not necessarily refer to the same implementation. A large number of possible implementations are contemplated, including those specifically disclosed, as well as modifications or alternatives that fall within the substance or scope of this disclosure.

[0192] This disclosure may discuss potential advantages that may arise from the disclosed embodiments. Not all specific implementations of all these embodiments will necessarily exhibit any or all of the potential advantages. Whether a particular embodiment achieves an advantage depends on many factors, some of which are outside the scope of this disclosure. In fact, there are many reasons why an embodiment falling within the scope of the claims may not exhibit some or all of any of the disclosed advantages. For example, a particular embodiment may include other circuitry outside the scope of this disclosure, in conjunction with one embodiment of the disclosed embodiments, which negates or diminishes one or more of the disclosed advantages. Furthermore, suboptimal design execution of a particular embodiment (e.g., the implementing technique or tool) may also negate or diminish the disclosed advantages. Even assuming an implementation of the technique, the realization of advantages may still depend on other factors, such as the environmental circumstances in which the implementation is deployed. For example, the inputs provided to a particular embodiment may prevent one or more problems addressed in this disclosure from occurring in a particular context, and as a result, the benefits of its solution may not be realized. In view of the existence of possible factors outside this disclosure, it is hereby expressed that any potential advantages described herein should not be construed as a limitation of the claims that must be satisfied in order to prove infringement. Rather, the identification of such potential advantages is intended to illustrate the types of improvements available to the designer who benefits from this disclosure. Describing such advantages permanently (e.g., stating that a particular advantage "may occur") is not intended to convey doubt about whether such advantages can actually be realized, but rather to recognize that the realization of such advantages often depends on the technological reality of additional factors.

[0193] Unless otherwise stated, the embodiments are non-limiting. That is, the disclosed embodiments are not intended to limit the scope of the claims drafted based on this disclosure, even where only a single example is described with respect to a particular feature. The disclosed embodiments are intended to be illustrative and not restrictive, without any statement to the contrary in this disclosure. Therefore, this application is intended to allow for claims covering the disclosed embodiments, as well as such alternatives, modifications, and equivalents, which will be apparent to those skilled in the art to the advantage of this disclosure.

[0194] For example, features in this application can be combined in any suitable manner. Therefore, new claims may be made for any such combination of features during the filing of this application (or an application claiming priority thereto). Specifically, referring to the appended claims, features of dependent claims may be combined with features of other dependent claims, including claims dependent on other independent claims, where appropriate. Similarly, features from the respective independent claims may be combined where appropriate.

[0195] Thus, although the appended dependent claims may be drafted such that each dependent claim depends from a single other claim, additional dependencies are also contemplated. Any combination of dependent features consistent with the present disclosure is contemplated, and such combinations may be claimed in this application or in another application. In short, the combinations are not limited to those specifically recited in the appended claims.

[0196] In appropriate cases, it is also contemplated that claims drafted in one format or statutory type (e.g., apparatus) are intended to support corresponding claims in another format or statutory type (e.g., method).

[0197] Since the present disclosure is a legal document, various terms and phrases may be subject to administrative and judicial interpretation. Notice is hereby given that the following paragraphs, as well as the definitions provided throughout the present disclosure, will be used to determine how to interpret claims drafted based on the present disclosure.

[0198] Unless the context clearly dictates otherwise, references to items in the singular form (i.e., a noun or noun phrase preceded by "a," "an," or "the") are intended to mean "one or more." Thus, without accompanying context, a reference to an "item" in a claim does not exclude additional instances of that item. A "plurality" of items refers to a collection of two or more items.

[0199] The word "may" is used herein in an enabling sense (i.e., having the potential to be able to), rather than in a mandatory sense (i.e., must).

[0200] The terms "comprising" and "including" and their forms are open-ended and mean "including but not limited to."

[0201] When the term "or" is used in the present disclosure in relation to a list of options, it will generally be understood to be used in an inclusive sense, unless the context otherwise provides. Thus, the statement "x or y" is equivalent to "x or y, or both," and thus encompasses 1) x but not y, 2) y but not x, and 3) both x and y. On the other hand, phrases such as "either x or y, but not both" make it clear that "or" is used in an exclusive sense.

[0202] The expressions “w, x, y, or z, or any combination thereof” or “...at least one of w, x, y, and z” are intended to cover all possibilities involving a single element up to the total number of elements in the set. For example, given the set [w, x, y, z], these phrases cover any single element in the set (e.g., w but not x, y, or z), any two elements (e.g., w and x, but not y or z), any three elements (e.g., w, x, and y, but not z), and all four elements. The phrase “...at least one of w, x, y, and z” therefore refers to at least one element in the set [w, x, y, z], thus covering all possible combinations of that list of elements. This phrase should not be interpreted as requiring the existence of at least one instance of w, at least one instance of x, at least one instance of y, and at least one instance of z.

[0203] In this disclosure, various “labels” may precede nouns or noun phrases. Unless the context otherwise provides, different labels used for features (e.g., “first circuit,” “second circuit,” “specific circuit,” “given circuit,” etc.) refer to different instances of the feature. Additionally, unless otherwise stated, the labels “first,” “second,” and “third” do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) when applied to features.

[0204] The phrase "based on" is used to describe one or more factors that influence the determination. This term does not exclude the possibility that additional factors might influence the determination. That is, the determination may be based solely on the specified factors or on the specified factors along with other unspecified factors. Consider the phrase "A is determined based on B." This phrase specifies that B is a factor used to determine A or that B influences the determination of A. This phrase does not exclude the possibility that the determination of A may also be based on some other factor (such as C). This phrase is also intended to cover implementations where A is determined solely based on B. As used herein, the phrase "based on" is synonymous with the phrase "at least partially based on."

[0205] The phrases “responding to” and “responding” describe one or more factors that trigger an effect. This phrase does not exclude the possibility that additional factors may influence or otherwise trigger the effect, whether these factors are used in conjunction with or independently of the specified factor. That is, the effect may respond solely to these factors, or it may respond to the specified factor as well as other unspecified factors. Consider the phrase “responding to B and executing A.” This phrase specifies that B is a factor that triggers the execution of A or triggers a specific result of A. This phrase does not exclude that the execution of A may also respond to certain other factors, such as C. This phrase also does not exclude that the execution of A may be jointly executed in response to B and C. This phrase is also intended to cover implementation schemes where A is executed solely in response to B. As used herein, the phrase “responding” is synonymous with the phrase “at least partially responding to.” Similarly, the phrase “responding to” is synonymous with the phrase “at least partially responding to.”

[0206] Within this disclosure, different entities (which may be referred to differently as “units,” “circuits,” other components, etc.) may be described or claimed to be “configured” to perform one or more tasks or operations. This expression—[entity] configured to [perform one or more tasks]—is used herein to refer to a structure (i.e., a tangible thing). More specifically, this expression is used to indicate that the structure is arranged to perform one or more tasks during operation. A structure may be considered “configured” to perform a task even if the structure is not currently being operated. Therefore, an entity described or stated as “configured” to perform a task refers to a physical thing used to perform that task, such as a device, circuit, system with processor units, and memory storing executable program instructions. This phrase is not used herein to refer to intangible things.

[0207] In some cases, various units / circuits / components may be described herein as a collection of entities that perform tasks or operations. It should be understood that these entities are "configured" to perform those tasks / operations, even if not specifically stated otherwise.

[0208] The term "configured as" is not intended to mean "able to be configured as." For example, an unprogrammed FPGA is not considered "configured as" to perform a specific function. However, the unprogrammed FPGA can be "configurable as" to perform that function. After proper programming, the FPGA can then be considered "configured as" to perform a specific function.

[0209] For the purposes of this U.S. patent application based on this disclosure, the statement in the claims that a structure is “configured” to perform one or more tasks is expressly intended not to invoke 35 USC § 112(f) for that claim element. If an applicant wishes to invoke part 112(f) during the filing of a U.S. patent application based on this disclosure, it will use the “component for [performing a function]” structure to state the elements of the claims.

[0210] Different “circuits” may be described in this disclosure. These circuits, or “circuits,” constitute hardware that includes various types of circuit elements, such as combinational logic, clock storage devices (e.g., flip-flops, registers, latches, etc.), finite state machines, memories (e.g., random access memory, embedded dynamic random access memory), programmable logic arrays, etc. Circuits may be custom-designed or taken from standard libraries. In various specific implementations, circuits may, as appropriate, include digital components, analog components, or a combination of both. Certain types of circuits may be commonly referred to as “cells” (e.g., decoding units, arithmetic logic units (ALUs), functional units, memory management units (MMUs), etc.). Such cells also refer to circuits.

[0211] Therefore, the circuits / units / components and other elements illustrated in the accompanying drawings and described herein include hardware elements, such as those described in the preceding paragraphs. In many cases, the internal arrangement of hardware elements in a particular circuit can be specified by describing the function of that circuit. For example, a particular “decoding unit” can be described as having the function of executing “the opcode of a processing instruction and routing that instruction to one or more of a plurality of functional units,” meaning that the decoding unit is “configured” to perform that function. To those skilled in the art of computers, this functional specification is sufficient to suggest a set of possible structures for the circuit.

[0212] In various implementations, as discussed in the preceding paragraphs, circuits, cells, and other elements can be defined by the functions or operations they are configured to perform. The arrangement of these circuits / cells / components relative to each other and the manner in which they interact form a microarchitecture definition of hardware, which is ultimately manufactured in an integrated circuit or programmed into an FPGA to form a physical implementation of the microarchitecture definition. Therefore, a microarchitecture definition is considered by those skilled in the art to be a structure from which many physical implementations can be derived, all of which fall within the broader structure described by the microarchitecture definition. That is, those skilled in the art, with the microarchitecture definition provided according to this disclosure, can implement this structure without excessive experimentation and using the application of a person of ordinary skill in the art, by encoding the description of the circuits / cells / components in a hardware description language (HDL) such as Verilog or VHDL. The HDL description is often expressed in a way that can be revealed as functional. However, for those skilled in the art, the HDL description is a way of translating the structure of a circuit, cell, or component into the details of the next level of implementation. Such HDL descriptions can take the following forms: behavioral code (which is typically non-synthesizable), Register Transfer Language (RTL) code (which is typically synthesizable compared to behavioral code), or structural code (e.g., a netlist specifying logic gates and their connectivity). HDL descriptions can be sequentially synthesized against a library of cells designed for a given integrated circuit manufacturing technology and can be modified for timing, power, and other reasons to obtain a final design database that is transferred to the factory to generate masks and ultimately produce integrated circuits. Some hardware circuitry or portions thereof can also be custom-designed in a schematic editor and captured into the integrated circuit design along with the synthesized circuitry. The integrated circuit may include transistors and other circuit elements (e.g., passive components such as capacitors, resistors, inductors, etc.), as well as interconnects between transistors and circuit elements. Some implementations may implement multiple integrated circuits coupled together to implement the hardware circuitry, and / or discrete components may be used in some implementations. Alternatively, the HDL design can be synthesized into a programmable logic array such as a Field Programmable Gate Array (FPGA) and implemented within the FPGA. This decoupling between the design of a set of circuits and their subsequent low-level implementations often leads to scenarios where circuit or logic designers never specify a particular set of structures for the low-level implementations that goes beyond a description of what the circuits are configured to do, because that process is performed at different stages of the circuit implementation process.

[0213] The fact that a circuit can be implemented to the same specifications using many different low-level combinations of circuit elements results in a large number of equivalent circuit structures. As noted, these low-level circuit implementations can vary depending on the manufacturing technology, the foundry chosen to manufacture the integrated circuit, the cell library provided for a particular project, and so on. In many cases, the choice of different design tools or methods to produce these different implementations can be arbitrary.

[0214] Furthermore, for a given implementation, a single concrete implementation of the circuit's specific functional specifications typically involves a large number of devices (e.g., millions of transistors). Therefore, the shearing volume of this information makes it impractical to provide a complete description of the low-level structure used to implement a single implementation, let alone a large number of equivalent possible implementations. To this end, this disclosure describes the structure of a circuit using functional abbreviations commonly used in industry.

Claims

1. An apparatus, the apparatus comprising: A processor front-end circuit, configured to extract instructions and decode the instructions; Prediction circuit, the prediction circuit being configured to predict the direction of control transfer commands; An execution circuit configured to speculatively execute instructions based on a predicted direction of a control transfer instruction; The result storage circuit is configured to record information about the destination register indicating a load instruction that is speculatively executed, including a first load instruction; A control flow tracker circuit, the control flow tracker circuit being configured to store information indicating a reconvergence point for the control transfer command; The reuse control circuit is configured to: Track the registers written by instructions prior to the re-convergence point; In response to a misprediction by the prediction circuit regarding the control transfer command: Based on the tracked registers, it is determined that the first load instruction does not depend on data from any instructions between the control transfer instruction and the reconvergence point; as well as As a result of the first load instruction, the value of the destination register of the record written using speculative execution based on the first load instruction is used, wherein the use is performed in response to the determination and despite the misprediction of the control transfer instruction.

2. The apparatus according to claim 1, wherein: The result storage circuit is configured to record information about the destination physical register of the load instruction to be speculatively executed; and The reuse control circuit is configured to prevent the release of the first physical register, which is instructed by the result storage circuit to store the value for the first load instruction, and to use the value from the first physical register for the first load instruction.

3. The apparatus according to claim 2, further comprising: A load information table register valid array circuit is configured to indicate a set of physical registers storing values ​​for potential reuse.

4. The apparatus of claim 1, wherein the control flow tracker circuit is further configured to store the position in the result storage circuit corresponding to the reconvergence point for the control transfer instruction.

5. The apparatus of claim 1, wherein the reuse control circuit is further configured to, in response to the misprediction, copy entries for instructions following the reconvergence point from the result storage circuit to the reuse storage circuit.

6. The apparatus of claim 5, wherein the reuse control circuitry is configured to compare a hash of the program counter with a tag field of a reuse storage circuit entry to determine the identity of the destination register of the record.

7. The apparatus of claim 1, wherein, in order to determine that the first loading instruction does not depend on data from any instruction between the control transfer instruction and the reconvergence point, the reuse control circuit is configured to: The registers are tracked by instructions written after the re-convergence point, which do not use source data from registers written by instructions prior to the re-convergence point.

8. The apparatus according to claim 1, wherein: The control flow tracker circuitry includes a live output mask field, which includes a corresponding indicator for each architecture register in the set of architecture registers supported by the device; and The reuse control circuit is configured as follows: The indicator in the live output mask field is set in response to the writing of the corresponding architecture register by the instruction between the control transfer instruction and the reconvergence point; as well as The indicator in the live output mask field is cleared in response to a write to the corresponding architecture register by an instruction that follows the reconvergence point and is independent of any instruction between the control transfer instruction and the reconvergence point.

9. The apparatus of claim 1, wherein the reuse control circuitry is configured to further use the value from the destination register of the record based on: Based on a comparison of the program counter of the first load instruction with a field of the entry in the result storage circuit for the first load instruction during re-execution; and The destination register for the record is validly determined.

10. The apparatus according to claim 1, further comprising: A filter circuit configured to prevent the reuse of the result of a load instruction based on the result of incorrect reuse of the load instruction caused by the result of a forwarded store instruction.

11. The apparatus according to claim 1, further comprising: An index mapping circuit is configured to map entries in the control flow tracker circuit to entries in the result storage circuit.

12. The apparatus of claim 1, wherein the apparatus is a computing device, the computing device further comprising: Central processing unit; monitor; and Network interface circuit.

13. A method, the method comprising: The computing device speculatively executes instructions based on a predicted direction of control transfer instructions; The computing device records information about the destination register of a load instruction that indicates speculative execution of a load instruction, including a first load instruction; The computing device stores information indicating the reconvergence point for the control transfer command; The computing device tracks the registers written by instructions prior to the reconvergence point; In response to a detected misprediction of the control transfer command, the computing device: Based on the tracked registers, it is determined that the first load instruction does not depend on data from any instructions between the control transfer instruction and the reconvergence point; as well as As a result of the first load instruction, the value of the destination register of the record written using speculative execution based on the first load instruction is used, wherein the use is performed in response to the determination and despite the misprediction of the control transfer instruction.

14. The method of claim 13, further comprising: The computing device records information about the destination physical register of the load instruction that is speculatively executed; as well as The computing device prevents the release of the first physical register that is instructed to store the value for the first load instruction, and uses the value from the first physical register for the first load instruction.

15. The method according to claim 13, further comprising: The record position corresponding to the reconvergence point is stored for the transfer control command.

16. The method of claim 13, wherein the determination includes tracking registers written by instructions following the re-convergence point, the instructions not using source data from registers written by instructions preceding the re-convergence point.

17. A non-transitory computer-readable storage medium thereon storing design information, the design information specifying at least a portion of a design of a hardware integrated circuit in a format recognizable by a semiconductor manufacturing system, the semiconductor manufacturing system being configured to use the design information to manufacture the circuit according to the design, wherein the design information specifying the circuit includes: A processor front-end circuit, configured to extract instructions and decode the instructions; Prediction circuit, the prediction circuit being configured to predict the direction of control transfer commands; An execution circuit configured to speculatively execute instructions based on a predicted direction of a control transfer instruction; The result storage circuit is configured to record information about the destination register indicating a load instruction that is speculatively executed, including a first load instruction; A control flow tracker circuit, the control flow tracker circuit being configured to store information indicating a reconvergence point for the control transfer command; The reuse control circuit is configured to: Track the registers written by instructions prior to the re-convergence point; In response to a misprediction by the prediction circuit regarding the control transfer command: Based on the tracked registers, it is determined that the first load instruction does not depend on data from any instructions between the control transfer instruction and the reconvergence point; as well as As a result of the first load instruction, the value of the destination register of the record written using speculative execution based on the first load instruction is used, wherein the use is performed in response to the determination and despite the misprediction of the control transfer instruction.

18. The non-transitory computer-readable storage medium according to claim 17, wherein: The result storage circuit is configured to record information about the destination physical register of the load instruction to be speculatively executed; and The reuse control circuit is configured to prevent the release of the first physical register, which is instructed by the result storage circuit to store the value for the first load instruction, and to use the value from the first physical register for the first load instruction.

19. The non-transitory computer-readable storage medium according to claim 18, wherein the non-transitory computer-readable storage medium further comprises: A load information table register valid array circuit is configured to indicate a set of physical registers storing values ​​for potential reuse.

20. The non-transitory computer-readable storage medium according to claim 17, wherein: The control flow tracker circuitry includes a live output mask field, which includes a corresponding indicator for each architecture register in the set of architecture registers supported by the circuitry; and The reuse control circuit is configured as follows: The indicator in the live output mask field is set in response to the writing of the corresponding architecture register by the instruction between the control transfer instruction and the reconvergence point; as well as The indicator in the live output mask field is cleared in response to a write to the corresponding architecture register by an instruction that follows the reconvergence point and is independent of any instruction between the control transfer instruction and the reconvergence point.

21. An apparatus comprising: A processor front-end circuit, configured to extract instructions and decode the instructions; Prediction circuit, the prediction circuit being configured to predict the direction of control transfer commands; An execution circuit configured to speculatively execute instructions based on a predicted direction of a first control transfer instruction; The result storage circuit is configured to record information indicating a determined direction for the speculative execution of a second control transfer instruction that is newer than the first control transfer instruction; A control flow tracker circuit, configured to store information indicating a reconvergence point for the first control transfer command; The reuse control circuit is configured to: Track the registers written by instructions prior to the re-convergence point; In response to a misprediction by the prediction circuit for the first control transfer command: The second control transfer instruction is determined based on the tracked registers and does not depend on data from any instruction between the first control transfer instruction and the reconvergence point; as well as In response to the determination, the recorded determined direction for the second control transfer instruction is used, despite the misprediction of the first control transfer instruction.

22. The apparatus of claim 21, wherein the reuse control circuitry is further configured to respond to the determination of a determined destination from the result storage circuitry for the second control transfer instruction.

23. The apparatus of claim 21, wherein after the second control transfer instruction is refreshed and replayed, the recorded determined direction is used for the second control transfer instruction, wherein the apparatus is configured not to redetermine the direction for the second control transfer instruction based on the recorded determined direction.

24. The apparatus according to claim 21, wherein: The control flow tracker circuitry includes a live output mask field, which includes a corresponding indicator for each architecture register of the set of architecture registers supported by the device. The reuse control circuit is configured as follows: The indicator in the live output mask field is set in response to the writing of the corresponding architecture register by the instruction between the first control transfer instruction and the reconvergence point; The indicator in the live output mask field is cleared in response to a write to the corresponding architecture register by an instruction that follows the reconvergence point and is independent of any instruction between the first control transfer instruction and the reconvergence point. as well as The second control transfer instruction is determined to be independent of data from any instruction between the first control transfer instruction and the reconvergence point based on the fact that one or more indicators in the live output mask field are clear, and the one or more indicators correspond to one or more input operands of the second control transfer instruction.

25. The apparatus of claim 24, wherein: The processor front-end circuitry is configured to decode multiple instructions within a given loop; and The reuse control circuitry is configured to set the live output mask field bits for one or more of a plurality of instructions decoded in a given loop, assuming that the target of one or more other instructions decoded in the given loop is set.

26. The apparatus of claim 24, wherein the reuse control circuitry is configured to copy the live output mask field to the reuse storage circuitry in response to the misprediction.

27. The apparatus of claim 21, wherein the reuse control circuit is further configured to, in response to the misprediction, copy entries for instructions following the reconvergence point from the result storage circuit to the reuse storage circuit.

28. The apparatus of claim 21, wherein the control flow tracker circuitry is further configured to determine the reconvergence point, the determination comprising: The range of multiple instruction addresses corresponding to the instructions executed between store and control transfer instructions; as well as During the replay of instructions following the misprediction, the reconvergence point is determined based on the match between the current program counter and one of the instruction ranges in the instruction range.

29. The apparatus of claim 21, wherein, in order to use the determined direction for the second control transfer instruction, the reuse control circuitry is configured to initiate a misprediction redirection to redirect the front-end circuitry for extraction based on the determined direction.

30. The apparatus of claim 29, wherein the reuse control circuitry is configured to fill in a field indicating the re-convergence point and a field indicating that the re-convergence point has been found in the control flow tracker circuitry.

31. The apparatus of claim 21, wherein the reuse control circuitry is configured to reuse the determined direction for the second control transfer command based on: Based on a comparison of the program counter of the second control transfer instruction with the field of the entry in the result storage circuit for the second control transfer instruction during re-execution; The determined direction is a valid determination; as well as The determined direction is different from the direction predicted by the prediction circuit for the second control transfer command.

32. The apparatus of claim 21, wherein the reuse control circuit is configured to use a predicted direction stored from the result storage circuit for a third control transfer instruction that is speculatively executed after an incorrect loading operation.

33. The apparatus of claim 21, wherein the apparatus is a computing device, the computing device further comprising: Central processing unit; monitor; and Network interface circuit.

34. A method, the method comprising: The computing device speculatively executes instructions based on a predicted direction of the first control transfer instruction; The computing device records information indicating a determined direction for the speculative execution of a second control transfer instruction that is newer than the first control transfer instruction; The computing device stores information indicating the reconvergence point for the first control transfer command; The computing device tracks the registers written by instructions prior to the reconvergence point; In response to a misprediction of the first control transfer command, the computing device: The second control transfer instruction is determined based on the tracked registers and does not depend on data from any instruction between the first control transfer instruction and the reconvergence point; as well as In response to the determination, the recorded determined direction for the second control transfer instruction is used, despite the misprediction of the first control transfer instruction.

35. The method of claim 34, further comprising: The computing device sets the indicator in the live output mask field in response to the writing of the corresponding architecture register by the instruction between the first control transfer instruction and the reconvergence point; as well as The computing device clears the indicator in the live output mask field by writing to the corresponding architecture register in response to an instruction following the reconvergence point that is independent of any instruction between the first control transfer instruction and the reconvergence point; The determination is based on the clearing of one or more indicators in the live output mask field, the one or more indicators corresponding to one or more input operands of the second control transfer instruction.

36. The method of claim 35, further comprising: The computing device decodes multiple instructions in a given loop; as well as For one or more instructions among a plurality of instructions decoded in a given loop, assume that the live output mask field bits are set for the target of one or more other instructions decoded in the given loop.

37. The method of claim 34, further comprising: The computing device stores multiple instruction address ranges corresponding to the instructions executed between control transfer instructions, and during the replay of instructions following the misprediction, the reconvergence point is determined based on the match between the current program counter and one of the instruction ranges.

38. A non-transitory computer-readable storage medium thereon storing design information, the design information specifying at least a portion of a design of a hardware integrated circuit in a format recognizable by a semiconductor manufacturing system, the semiconductor manufacturing system being configured to use the design information to manufacture the circuit according to the design, wherein the design information specifying the circuit includes: A processor front-end circuit, configured to extract instructions and decode the instructions; Prediction circuit, the prediction circuit being configured to predict the direction of control transfer commands; An execution circuit configured to speculatively execute instructions based on a predicted direction of a first control transfer instruction; The result storage circuit is configured to record information indicating a determined direction for the speculative execution of a second control transfer instruction that is newer than the first control transfer instruction; A control flow tracker circuit, configured to store information indicating a reconvergence point for the first control transfer command; The reuse control circuit is configured to: Track the registers written by instructions prior to the re-convergence point; In response to a misprediction by the prediction circuit for the first control transfer command: The second control transfer instruction is determined based on the tracked registers and does not depend on data from any instruction between the first control transfer instruction and the reconvergence point; as well as In response to the determination, the recorded determined direction for the second control transfer instruction is used, despite the misprediction of the first control transfer instruction.

39. The non-transitory computer-readable storage medium according to claim 38, wherein: The control flow tracker circuitry includes a live output mask field, which includes a corresponding indicator for each architecture register in the set of architecture registers supported by the circuitry. The reuse control circuit is configured as follows: The indicator in the live output mask field is set in response to the writing of the corresponding architecture register by the instruction between the first control transfer instruction and the reconvergence point; The indicator in the live output mask field is cleared in response to a write to the corresponding architecture register by an instruction that follows the reconvergence point and is independent of any instruction between the first control transfer instruction and the reconvergence point. as well as The second control transfer instruction is determined to be independent of data from any instruction between the first control transfer instruction and the reconvergence point based on the fact that one or more indicators in the live output mask field are clear, and the one or more indicators correspond to one or more input operands of the second control transfer instruction.

40. The non-transitory computer-readable storage medium of claim 38, wherein, in order to use the determined direction for the second control transfer instruction, the reuse control circuitry is configured to initiate a misprediction redirection to redirect the front-end circuitry for extraction based on the determined direction.

Images