Load Dependency Branch Prediction

Abstract

Load-dependent branch prediction is described. According to the described technique, a load-dependent branch instruction is detected by identifying that a destination location of a load instruction is used in an operation to determine whether a conditional branch is taken or not taken. The load instruction is included in a sequence of load instructions having addresses separated by a step size. An instruction is injected into the processor's instruction stream to fetch data of a future load instruction using the address of the load instruction offset by a distance based on the step size. An additional instruction is injected into the processor's instruction stream to pre-calculate the outcome of the load-dependent branch using an address calculated based on the address of the operation and the data of the future load instruction.

Description

[Technical field]

[0001] (Related Applications) This application claims the benefit of U.S. patent application Ser. No. 17 / 699,855, entitled "Load Dependent Branch Prediction," filed March 21, 2022, the disclosure of which is incorporated by reference in its entirety into this specification. [Background technology]

[0002] When a conditional branch instruction is identified in a processor's instruction pipeline, a branch predictor predicts whether the outcome of the conditional branch will be either taken or not taken, before the outcome is explicitly known. Instructions are then speculatively executed based on the predicted outcome. If the predicted outcome is correct, the speculatively executed instructions are used, avoiding delays. If the predicted outcome is incorrect, the speculatively executed instructions are discarded and the instruction stream cycles are restarted using the correct outcome, which introduces delays.

[0003] The detailed description will now be made with reference to the accompanying drawings. [Brief description of the drawings]

[0004] [Figure 1] FIG. 2 is a block diagram of a non-limiting example system having a prefetch controller for prefetching data that is likely to be requested by an execution unit of the system in accordance with one or more embodiments. [Diagram 2] FIG. 13 illustrates a non-limiting example of a representation of an array having elements used in a conditional branch. [Figure 3A] FIG. 1 illustrates a non-limiting example of a system that improves branch prediction by pre-calculating the outcome of load-dependent branches based on the predictability of the addresses of future load instructions. [Figure 3B]FIG. 1 illustrates a non-limiting example of a system that improves branch prediction by pre-calculating the outcome of load-dependent branches based on the predictability of the addresses of future load instructions. [Figure 4] FIG. 2 illustrates a procedure in an exemplary embodiment for injecting instructions into a processor's instruction stream to fetch data for a future load instruction. [Diagram 5] FIG. 2 illustrates a procedure in an exemplary embodiment for injecting instructions into a processor's instruction stream to pre-compute the outcome of a load-dependent branch. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0005] (overview) Branch prediction generally refers to a technique in which the outcome of a conditional branch instruction (e.g., taken or not taken) is predicted before the outcome is definitely known. Instructions are then fetched and speculatively executed based on the predicted outcome. If the predicted outcome is correct, the speculatively executed instructions are usable and delays are avoided. If the predicted outcome is incorrect, the speculatively executed instructions are discarded and the instruction stream cycles back again using the correct outcome, which introduces delays. Thus, increasing the accuracy of predictions made by a processor's branch predictor improves the overall performance of the processor by avoiding delays associated with inaccurate predictions.

[0006] The outcome of a conditional branch instruction that depends on data fetched by a separate load instruction (a load-dependent branch) is often inaccurately predicted by a branch predictor because the data fetched by the separate load instruction is usually random and / or difficult to predict in advance. As a result, conventional techniques that predict the outcome of a branch based on, for example, the branch history, are unable to consistently and accurately predict the outcome of a load-dependent conditional branch.

[0007] If the outcome of a load-dependent branch is incorrectly predicted, the instructions speculatively executed based on the incorrect prediction are discarded. This unnecessarily consumes processor resources, for example, causing delays to execute instructions based on the correct outcome. To improve the accuracy of predicted outcomes of load-dependent branches, the techniques described herein use existing hardware of the processor to identify striding load driven branch pairs in the instruction stream and pre-compute the outcome of each load-dependent branch. This includes identifying load instructions that are included in a sequence of load instructions that have predictable addresses. The predictability of these addresses is used to fetch data for future load instructions, which the described system uses to pre-compute the outcome of the load-dependent branch. The pre-computed results are significantly more accurate than results predicted for load-dependent branches based on random data.

[0008] In connection with precomputing the outcome of a load-dependent branch, a stride prefetcher of the processor populates a table accessible to a decode unit of the processor based on training events. In one example, the stride prefetcher communicates training events to the table (e.g., via a bus of the processor) based on the stride prefetch (e.g., when the stride prefetcher is updated or when it issues a prefetch request). In one or more embodiments, the training events include a program counter value, a step size, and a confidence level. By way of example, the program counter value is an instruction address and the step size corresponds to the difference between consecutive memory addresses accessed by instructions having the same program counter value. In at least one example, the confidence level is based on the number of times instructions having the same program counter value have accessed consecutive memory addresses separated by the step size.

[0009] Using the populated table, the decode unit monitors load instructions in the processor's instruction stream and compares the program counter value of the load instruction with the program counter values ​​of entries contained in the table. If the program counter value of the load instruction matches the program counter value of an entry in the table, the destination location (e.g., destination register) of the load instruction is captured and the matching entry in the table is updated to include the destination location.

[0010] According to the described technique, the decode unit receives information about conditional branch instructions in the instruction stream from a branch predictor. By way of example, this information includes an identifier, a prediction accuracy, and a source register for each conditional branch instruction. In at least one variation, the identifier associates the conditional branch instruction with a particular loop iteration, and the prediction accuracy indicates the confidence of a predicted outcome for the conditional branch instruction. If a predicted outcome of the conditional branch instruction has low prediction accuracy (e.g., meets a low accuracy threshold), the predicted outcome is a candidate for being replaced with a precomputed outcome of the conditional branch instruction.

[0011] Using the information received about the conditional branch instructions, the decode unit monitors the source registers of identified conditional branch instructions in the instruction stream to identify whether those instructions use the destination location of an active stride load included in the table. For example, the decode unit compares register numbers to determine whether the monitored source registers of the incoming conditional branch instructions use the destination location of the stride load, e.g., the destination register. The decode unit detects that the conditional branch instruction is a load-dependent branch instruction if the destination location of the active stride load is used (directly or indirectly) in the monitored source register of the conditional branch instruction. Conditional branch instructions are "load-dependent" because the outcome of the instruction (e.g., whether the branch is taken or not taken) depends on the data of a future load instruction, which may be random and / or nearly unpredictable. However, the load address is predictable, even though the data itself is random.

[0012] In response to detecting a load-dependent branch instruction, the branch detector injects or inserts an instruction into the decoded instruction stream to fetch data for the future load instruction. In one or more embodiments, the injected instruction includes an address that is determined, for example from a table, by offsetting the address of the active stride load by a distance determined based on the step size of the active stride load.

[0013] A load store unit of the processor receives the injected instructions and fetches data of the future load instructions. For example, the load store unit writes the data of the future load instructions to a temporary location (or register) of the processor available to the decode unit. In one or more embodiments, the branch detector injects additional instructions into the instruction stream, and the execution unit uses the additional instructions to pre-calculate the outcome of the load-dependent branch (e.g., according to whether the branch is determined to be taken or not taken), such as by using an address calculated based on the data of the future load instruction. The pre-calculated results are stored in a pre-calculated branch table available to the branch predictor.

[0014] Using this table and the distance of the injected future load from the load instruction, future iterations of the corresponding conditional branch instruction are identified. If the branch predictor has not yet reached the future iteration, it uses the precomputed result as the predicted outcome of the conditional branch before the outcome is explicitly known. Because the actual outcome of the branch is not explicitly known, each instruction corresponding to a precomputed result is executed "speculatively." However, if the branch predictor has already passed the future identifier, it optionally performs an early redirection. Performing an early redirection saves many cycles compared to redirection performed by the execution unit.

[0015] By including a branch detector with the use of the described technique, the processor improves predictions for stride load-dependent branches in a power-saving manner. The use of precomputed results improves processor performance compared to conventional processors, since the precomputed results of load-dependent conditional branch instructions are more accurate than those predicted by a conventionally configured branch predictor. For example, this increases the likelihood that an instruction speculatively executed based on a precomputed result will be usable rather than discarded. Additionally, even if the precomputed results are not used and early redirection is performed, the early redirection still saves multiple cycles over redirection performed by the execution unit. This also improves processor performance. As a result, the described technique demonstrates substantial improvements in processor performance over a baseline that does not implement the described technique.

[0016] In some aspects, techniques described herein relate to a method that includes detecting a load dependent branch instruction by identifying that a destination location of a load instruction is used in an operation to determine whether a conditional branch is taken or not taken, where the load instruction is included in a sequence of load instructions having addresses separated by a step size, and injecting an instruction into the instruction stream of a processor to fetch data for a future load instruction using the address of the load instruction offset by a distance based on the step size.

[0017] In some aspects, the techniques described herein relate to a method that further includes injecting additional instructions into the instruction stream to pre-calculate the outcome of a load dependent branch using an address calculated based on the address of the operation and data of the future load instruction.

[0018] In some aspects, the techniques described herein relate to a method further including writing an indication of the result to a pre-computed branch table.

[0019] In some aspects, the techniques described herein relate to a method, where a load-dependent branch instruction is detected in a decode unit of an instruction stream.

[0020] In some aspects, the techniques described herein relate to a method, where the distance is a product of the step size and the number of steps.

[0021] In some aspects, the techniques described herein relate to a method, where instructions are injected into an instruction stream via an injection bus of a processor.

[0022] In some aspects, the techniques described herein relate to a method that further includes storing data for a future load instruction in a temporary register or location accessible to a decode unit of the processor.

[0023] In some aspects, the technology described herein relates to a method, wherein the operation is a comparison operation, and the load dependent branch instruction is detected based on a prediction accuracy of the conditional branch.

[0024] In some aspects, the techniques described herein relate to a method, where a load dependent branch instruction is detected based on a confidence level for the load instruction.

[0025] In some aspects, the technology described herein relates to a system that includes a decode unit of a processor configured to identify that a destination location of a load instruction is used in an operation to determine whether a conditional branch is taken or not taken, where the load instruction is included in a sequence of load instructions having addresses separated by a step size, and a branch detector of the processor configured to inject an instruction into the instruction stream of the processor to fetch data for a future load instruction using the address of the load instruction offset by a distance based on the step size.

[0026] In some aspects, the techniques described herein relate to a system, where the branch detector is further configured to inject additional instructions into the instruction stream to pre-calculate the outcome of a load-dependent branch using an address calculated based on the address of the operation and data of a future load instruction.

[0027] In some aspects, the technology described herein relates to a system further including an execution unit of the processor configured to write resulting instructions to a pre-computed branch table.

[0028] In some aspects, the techniques described herein relate to a system where data for future load instructions is stored in a temporary register or location accessible to a decode unit.

[0029] In some aspects, the techniques described herein relate to a system where the distance is the product of the step size and the number of steps.

[0030] In some aspects, the technology described herein relates to a system where instructions are injected into an instruction stream via an injection bus of a processor.

[0031] In some aspects, the techniques described herein relate to a method that includes detecting a load dependent branch instruction by identifying that a destination location of the load instruction is used in an operation to determine whether a conditional branch is taken or not taken, where the load instruction is included in a sequence of load instructions having addresses separated by a step size, and injecting instructions into the instruction stream of a processor to pre-calculate a result of the load dependent branch based on the address of the operation and data of future load instructions fetched using the step size.

[0032] In some aspects, the techniques described herein relate to a method, where data for a future load instruction is fetched using the address of the load instruction offset by a distance based on a step size.

[0033] In some aspects, the techniques described herein relate to a method that further includes storing data for a future load instruction in a temporary register or location accessible to a decode unit of the processor.

[0034] In some aspects, the techniques described herein relate to a method further including writing an indication of the result to a pre-computed branch table.

[0035] In some aspects, the technology described herein relates to a method, wherein the operation is a comparison operation, and the load dependent branch instruction is detected based on a prediction accuracy of the conditional branch.

[0036] 1 is a block diagram of a non-limiting exemplary system 100 having a prefetch controller for prefetching data likely to be required by an execution unit of the system in accordance with one or more embodiments. In particular, system 100 includes a fetch unit 102, a decode unit 104, an execution unit 106, and a load store unit 108 of a processor.

[0037] In one or more embodiments, a program counter (not shown) of the processor indicates instructions to be processed by the processor as part of instruction stream 110. By way of example, fetch unit 102 fetches instructions indicated by the program counter, and decode unit 104 decodes the fetched instructions for execution by execution unit 106. In at least one variation, the program counter is incremented after an instruction is fetched to indicate the next instruction to be executed as part of instruction stream 110.

[0038] According to the described technique, the execution unit 106 requests data to execute an instruction. In a variant, the cache 112 is first searched for the requested data. In one or more embodiments, the cache 112 is a memory cache, such as a particular level of cache (e.g., an L1 cache or an L2 cache), which is included in a hierarchy of multiple cache levels (e.g., L0, L1, L2, L3, L4). If the requested data is available in the cache 112 (e.g., a cache hit), the load store unit 108 can quickly provide the requested data from the cache 112. However, if the requested data is not available in the cache 112 (e.g., a cache miss), the requested data is retrieved from a data store, such as the memory 114.

[0039] It should be appreciated that memory 114 (e.g., random access memory) is one example of a data store from which data can be retrieved and / or loaded into cache 112 if not already stored therein, for example, using the prefetching techniques described above and below. Other examples of data stores include, but are not limited to, external memory, higher level caches (e.g., an L2 cache if cache 112 is an L1 cache), secondary storage (e.g., mass storage devices), and removable media (e.g., flash drives, memory cards, compact disks, digital video disks), to name a few. In particular, serving requested data from a data store when a cache miss occurs is slower than serving requested data from cache 112 when a cache hit occurs.

[0040] To avoid cache misses that increase latency, the load store unit 108 includes a prefetch controller 116 that identifies patterns in memory addresses that are accessed when the execution units 106 execute instructions. The identified patterns can be used to determine memory addresses in the memory 114 that contain data that the execution units 106 are likely to request in the future. The prefetch controller 116 and / or the load store unit 108 "prefetch" data from the determined memory addresses in the memory 114 and store the prefetched data in the cache 112, for example, before the execution units 106 request the prefetched data for execution of an instruction of the instruction stream 110 that uses the prefetched data. In accordance with the described techniques, for example, the data that is requested and prefetched in connection with executing an instruction corresponds to an array, an example of which is described in more detail with respect to FIG. 2.

[0041] Prefetch controller 116 can identify various different types of patterns in memory addresses accessed when execution unit 106 executes instructions included in instruction stream 110. In the illustrated example, prefetch controller 116 includes various prefetchers that correspond to examples of those different types of patterns. However, it should be understood that in one or more embodiments, prefetch controller 116 includes fewer, more, or different prefetchers without departing from the spirit or scope of the described technology. By way of example and not limitation, prefetch controller 116 includes next line prefetcher 118, stream prefetcher 120, stride prefetcher 122, and other prefetcher 124.

[0042] In one or more embodiments, next line prefetcher 118 identifies a request for a line of data and prefetches the next line of data for loading into cache 112 (e.g., by communicating a prefetch instruction to load store unit 108). Stream prefetcher 120 can prefetch data multiple lines ahead of the requested data by identifying a first data access of a stream, determining a direction of the stream based on a second data access of the stream, and then determining based on a third data access that the first, second, and third data accesses are associated with the stream, etc. Based on this, stream prefetcher 120 initiates prefetching of data for the stream, e.g., by communicating at least one prefetch instruction to load store unit 108.

[0043] Stride prefetcher 122 is similar to stream prefetcher 120, but stride prefetcher 122 is capable of identifying memory address access patterns that follow a "stride" or "step size," such as by identifying a pattern in some memory location between the beginning of the locations where data is accessed. In one or more embodiments, the "stride" or "step size" is measured in bytes or other units.

[0044] In one example, the stride prefetcher 122 identifies a location in memory (e.g., a first memory address) of a beginning of a first element associated with the access. In this example, the stride prefetcher 122 determines a direction and a "step size" or "stride" based on a location in memory of a beginning of a second element associated with the access (e.g., a second memory address), whereby the stride or step size corresponds to a number of locations in memory between the beginning of the first element and the beginning of the second element. In one or more embodiments, the stride prefetcher 122 confirms the pattern based on further determining that a location in memory of a beginning of a third element associated with the access (e.g., a third memory address) is also a "stride" or "step size" away from the location in memory of the beginning of the second element. The stride prefetcher 122 is then configured to initiate prefetching of the respective data based on the stride or step size.

[0045] In at least one variant, the stride prefetcher 122 stores a program counter value, a stride or step size, and / or other information, examples of which include a confidence level and a virtual address. In the illustrated example, the stride prefetcher 122 is shown to include or otherwise have access to a table 126. Further, the table 126 is shown to have entries having a valid field 128, a program counter field 130, a stride field 132, and other fields 134. In one or more embodiments, the table 126 includes one or more entries corresponding to at least one sequence of instructions processed by the system 100. The inclusion of ellipses in the figure represents the ability of the table 126, in at least one variant, to maintain more than one entry. For each entry in the table 126 associated with an instruction sequence, a respective value is stored in a field of the table 126, such as the valid field 128, the program counter field 130, the stride field 132, and / or other fields 134.

[0046] In one example, an entry in table 126 corresponds to a sequence of load and store instructions. In program counter field 130, load store unit 108 or prefetch controller 116 stores a program counter value that, in one or more scenarios, is an instruction address shared by instructions in the sequence of instructions (e.g., sequential instructions). In at least one variation, only a portion of the program counter value is stored in the entry's program counter field 130, e.g., to reduce the number of bits used to store the entry in table 126 compared to including the entire program counter value in the entry's field. In another example, a program counter hash value is calculated from the program counter value (e.g., using a hash function) and stored in program counter field 130 to reduce the number of bits used to store the entry in table 126.

[0047] In the stride field 132, the load store unit 108 or prefetch controller 116 stores a determined step size between locations in memory (e.g., memory addresses) accessed at the beginning of elements of the array for instructions in a sequence of instructions (e.g., sequential instructions). In one or more embodiments, the table 126 stores other information about the entries in other field 134, such as a confidence level, a virtual address, and various other information. As an example, the other information includes the number of memory addresses accessed by an instruction in a sequence of instructions separated by the step size indicated in the stride field 132.

[0048] Other prefetcher 124 represents additional data prefetching functionality. In one or more variations, for example, other prefetcher 124 is capable of correlated prefetching, tag-based correlated prefetching, and / or pre-execution based prefetching, to name a few. In one or more embodiments, the prefetching functionality of other prefetcher 124 is used to augment or replace the functionality of next line prefetcher 118, stream prefetcher 120, and / or stride prefetcher 122.

[0049] As mentioned above, in at least one variation, the program counter is incremented after an instruction is fetched to indicate the next instruction to be executed as part of the instruction stream 110. If the sequence of input instructions includes a conditional branch instruction (or a conditional jump), the branch predictor 136 predicts whether the branch (or the jump) will be taken or not taken. The reason for this prediction is that whether the branch (or the jump) will be taken or not is not known for certain until the condition is actually calculated during execution, e.g., in the execution unit 106. If, during execution, the result of the conditional branch instruction is that the branch is taken, the program counter is set to the argument (e.g., address) of the conditional branch instruction. However, if, during execution, the result of the conditional branch instruction is that the branch is not taken, the program counter indicates that the instruction following the conditional branch instruction is the next instruction to be executed in the sequence of input instructions. The branch predictor 136 is configured to predict whether the branch is taken or not so that the instructions can be fetched for speculative execution, rather than waiting to execute the instructions until the result (branch taken or not) is calculated during execution. Waiting for the system 100 to execute those instructions would result in processing delays.

[0050] In an attempt to avoid such delays, if the branch predictor 136 predicts the branch not taken, the branch predictor 136 causes the instructions following the conditional branch instruction to be fetched and speculatively executed. Alternatively, if the branch predictor 136 predicts the branch taken, the branch predictor 136 causes the instructions at the memory location indicated by the argument of the conditional branch instruction to be fetched and speculatively executed. If the branch predictor 136 correctly predicts the outcome of the conditional branch instruction, the speculatively executed instructions are available, thereby avoiding the delays discussed above. However, if the branch predictor 136 incorrectly predicts the outcome of the conditional branch instruction, the speculatively executed instructions are discarded and the fetch unit 102 fetches the correct instructions for execution by the execution unit 106, which causes a delay. Thus, increasing the accuracy of the branch outcomes predicted by the branch predictor 136 reduces the number of incorrect predictions, and therefore the delays corresponding to such incorrect predictions, which is one way of improving the performance of the processor. Consider the following description of FIG. 2 in the context of identifying stride loads associated with load-dependent branches.

[0051] 2 illustrates a non-limiting example 200 of a representation of an array having elements used in a conditional branch. In this example 200, the representation shows a first memory address 202, a second memory address 204, a third memory address 206, a fourth memory address 208, and a fifth memory address 210, which correspond to locations in memory of the start of elements of an array 212. Furthermore, elements of array 212 are used in the conditional branch.

[0052] In the example 200, the elements of the array 212 include a first element 214, a second element 216, a third element 218, a fourth element 220, and a fifth element 222. As shown, the first memory address 202 corresponds to the beginning of the first element 214 of the array 212, which is further used in a conditional branch 224 that includes that element (e.g., X[0]). Also in this example, the second memory address 204 corresponds to the beginning of the second element 216 of the array 212, which is further used in a conditional branch 226 that includes that element (e.g., X[1]). The third memory address 206 corresponds to the beginning of the third element 218 of the array 212, which is further used in a conditional branch 228 that includes that element (e.g., X[2]). The fourth memory address 208 corresponds to the beginning of a fourth element 220 of the array 212, which is further used in a conditional branch 230 that includes that element (e.g., X[3]). The fifth memory address 210 corresponds to the beginning of a fifth element 222 of the array 212, which is further used in a conditional branch 232 that includes that element (e.g., X[4]). It should be understood that the array 212 is only an example, and that the described techniques operate on arrays of different sizes and refer to different types of conditional branching without departing from the spirit or scope of the techniques described herein. By way of example, in one or more embodiments, the conditional branching involves comparing an element of the array to a constant, comparing the results of a function applied to the element of the array (using the value directly), or comparing an element of the array to another source register, just to name a few.

[0053] In this example 200, the difference between memory addresses 202-210 corresponding to the locations in memory of the beginning of successive elements of array 212 is 4 (e.g., 4 bytes). Thus, in this example 200, the stride or step size of array 212 is 4. Thus, memory addresses 202-210 are predictable using a difference of 4. If array 212 includes a sixth element (not shown), the sixth memory address at which the sixth element of array 212 begins is likely to be equal to fifth memory address 210 (e.g., "116") + 4 (e.g., or "120"). It should be understood that in various systems, depending on various conditions, the difference in memory addresses corresponding to the locations in memory of the beginning of successive elements of the array may be different than 4 without departing from the spirit or scope of the described technology.

[0054] Unlike memory addresses 202-210, which are predictable using a difference of 4, the branch conditions do not follow such a pattern in the illustrated example.In the context of improving conditional branch prediction, consider the following example.

[0055] 3A and 3B illustrate a non-limiting example 300 of a system that improves branch prediction by pre-calculating the outcome of load-dependent branches based on the predictability of the addresses of future load instructions.

[0056] 3A illustrates an example system 300 having a branch detector in accordance with one or more embodiments. Specifically, the example system 300 includes a decode unit 104, an execution unit 106, a load store unit 108, a cache 112, a stride prefetcher 122, and a branch predictor 136. In one or more embodiments, the example system 300 includes a branch detector 302 that is part of, or potentially accessible to, the decode unit 104 in one or more embodiments. In accordance with the described techniques, both the stride prefetcher 122 and the branch predictor 136 train the branch detector 302 to monitor the input instruction stream 110 to identify stride load driven branch pairs, as described below, where the branch outcome depends on a high confidence stride load and the branch itself has low prediction accuracy.

[0057] In this example 300, branch detector 302 includes or otherwise has access to table 304 and table 306. Alternatively or additionally, decode unit 104 includes or otherwise has access to table 304 and table 306. Also, branch predictor 136 includes or otherwise has access to table 308.

[0058] FIG. 3B illustrates in more detail the tables available to the example system 300 in one or more embodiments. In particular, FIG. 3B illustrates in more detail the tables 304 and 308. As described below, the table 306 is populated to maintain information about branch instructions and is not shown in FIG. 3B. In one or more embodiments, the stride prefetcher 122 populates the table 304 to maintain information about stride loads. In this example, the table 304 includes entries having a valid field 310, a program counter field 312, a stride field 314, an active field 316, a destination register field 318, a trained field 320, a stride load register number field 322, and a confidence field 324. It should be understood that in one or more embodiments, the table 304 includes different fields without departing from the spirit or scope of the described technology. The table 304 is illustrated with an oval to indicate that the table 304 can maintain multiple entries having such fields.

[0059] As part of training the branch detector 302, the stride prefetcher 122 detects stride loads and populates table 304 with information about those loads. In populating table 304, the stride prefetcher 122 communicates (e.g., over the processor's bus) a training event to table 304 each time the stride prefetcher 122 makes a prefetch request, the training event including a program counter value, a step size (stride), and a confidence level. The program counter value is an instruction address, and the step size is the difference between consecutive memory addresses accessed by instructions (e.g., instructions in a loop) having the same program counter value. The confidence level is the number of times that instructions having the same program counter value access consecutive memory addresses separated by the step size. To populate table 304, the program counter value of each training event is compared to the program counter value stored in the program counter field 312 of each entry in table 304. The program counter value of the training event either matches a program counter value stored in the program counter field 312 of at least one entry in the table 304, or does not match a program counter value stored in the program counter field 312 of any entry in the table 304.

[0060] According to the described technique, the stride prefetcher 122 populates the table 304 based in part on the confidence level of the training event. In one example, a training event matches an entry in the table 304 if, for example, the program counter value of the training event matches the program counter value in the program counter field 312 of the entry. If the confidence level of the training event is low (e.g., does not meet a threshold confidence level), the entry is invalidated by setting the value stored in the valid field 310 to indicate that the entry is invalid. In one or more embodiments, the valid field 310 corresponds to a validity bit, and an entry is invalidated by setting the validity bit of the validity field 310 equal to "0". In contrast, in one or more embodiments, if the validity bit of the validity field 310 is equal to "1", the entry is valid. It should be understood that the validity field 310 may indicate validity and invalidity in other ways without departing from the spirit or scope of the described technique. In a scenario where a training event matches an entry in the table and the confidence level of the training event is high (e.g., meets a threshold confidence level), the step size of the training event can be used to update the stride field 314 of the respective entry, for example, if the step size of the training event does not match the step size already stored in the stride field 314 of the entry.

[0061] In one example, a training event does not match an entry in table 304 if, for example, the program counter value of the training event does not match the program counter value in the program counter field 312 of any entry. In this example, if the confidence level of the training event is low (e.g., does not meet a threshold confidence level), the training event is discarded and table 304 is not updated based on the training event. Instead, the program counter value of the subsequent training event is compared to the program counter value contained in the program counter field 312 of the entry in table 304.

[0062] In contrast to the scenario described above, if the confidence level of the non-matching training event is high (e.g., meets a threshold confidence level), a new entry is added to table 304 and the valid field 310 is set to indicate that the new entry is valid, e.g., by setting the validity bit of the valid field 310 of the new entry equal to "1". The new entry in table 304 is further populated based on the training event. For example, the program counter field 312 of the new entry in table 304 is updated to store the program counter value of the training event, and the stride field 314 of the new entry in table 304 is updated to store the step size of the training event.

[0063] After table 304 is populated based on training events from stride prefetcher 122, decode unit 104 accesses table 304 to compare the program counter value of a load instruction in instruction stream 110 with the program counter value contained in program counter field 312 of an entry in table 304, such as by using an associative memory so that the comparison is completed quickly, e.g., in one clock cycle. In one or more embodiments, the load instruction whose value is compared is a "younger" instruction, which in at least one example is an instruction that is received after an entry in table 304 with a matching program counter value is populated. If a matching new instruction is found, the entry in table 304 that matches is an active stride load.

[0064] In addition to being trained by the stride prefetcher 122, the branch detector 302 is also trained by the branch predictor 136. In accordance with the described techniques, for example, the branch predictor 136 communicates a conditional branch instruction 326 to the branch detector 302 (e.g., via a processor bus) for each branch instruction identified by the branch predictor 136. In accordance with the described techniques, the branch instruction 326 includes a prediction accuracy 328, an identifier 330, and a source register 332 of the conditional branch instruction.

[0065] In general, the identifier 330 identifies a conditional branch instruction, and the identifier 330 may be configured in different ways in various embodiments, examples of which include a program counter value or a hash of the program counter value. In one or more embodiments, the identifier 330 associates the conditional branch instruction with a particular loop iteration. The prediction precision 328 represents the confidence in the predicted outcome of the respective conditional branch instruction. The inclusion of the prediction precision 328 as part of the branch instruction 326 differs from traditionally configured branch instructions that do not include such prediction precision. In one or more embodiments, the branch instruction 326 is associated with multiple sources such that the instruction includes two or more source registers 332. In such embodiments, the other source registers, other than the source register corresponding to the stride load, correspond to invariants in the respective loop.

[0066] Branch instructions 326 communicated by the branch predictor 136 are used to populate the table 306. By way of example, the table 306 includes one or more entries, each corresponding to at least one branch instruction 326. In one or more embodiments, an entry in the table 306 includes fields to capture information of the branch instruction 326, such as fields to capture a prediction accuracy 328, an identifier 330, and a source register 332 of the branch instruction 326. Branch instructions with different identifiers correspond to different entries in the table 306. In accordance with the described technique, each entry includes a confidence field. In at least one variation, if a received branch instruction matches a stride load with an entry in the table 304, the confidence field of the entry is updated (e.g., to indicate a higher confidence). It should be appreciated that the confidence of an entry in the table 306 is updated based on different events in one or more embodiments.

[0067] As part of determining whether the branch instruction 326 is “load dependent”, the branch detector 302 determines whether the source register 332 indicated in the branch instruction 326 uses the destination register of the active stride load, e.g., based on matching with the destination register field 318 of the entry in the table 304. The branch detector 302 identifies instructions with low prediction accuracy 328 and identifies candidates for injecting the instruction (e.g., for precomputing the branch outcome) by identifying that the destination register field 318 of the entry in the table 304 corresponding to the active stride load matches the source register field 332 of the identified instruction. In one or more embodiments, the confidence field 324 of the entry corresponding to the active stride load indicates a high confidence of the stride load. By way of example, a “high” confidence that the entry in the table 304 corresponds to the stride load is based on the value indicating the confidence in the confidence 324 field meeting a threshold confidence.

[0068] In particular, the branch detector 302 compares register numbers of instructions rather than memory addresses by attempting to match the destination register field 318 of an entry in the table 304 with the source register field 332 of the branch instruction 326. Because register numbers are generally smaller than memory addresses (e.g., 5 bits vs. 64 bits), the hardware required by the described system to identify stride load driven branch pairs is reduced relative to prior art techniques.

[0069] In one or more examples, the destination register included in the destination register field 318 is used directly by the source register 332. In other examples, the match is identified by determining that the destination register indicated in the destination register field 318 of the active stride load's entry is used in an operation to determine whether a branch of a particular conditional branch instruction is taken or not taken. For example, the particular conditional branch instruction is a conditional jump instruction, and the destination register included in the destination register field 318 of the active stride load's entry is used in a comparison operation (or another operation) to determine whether a condition is met to jump to an instruction specified by the conditional jump instruction.

[0070] Based on a match between the stride load and the conditional branch (a stride load driven branch pair), if both the stride load and the conditional branch have confidence levels that meet their respective thresholds, the branch detector 302 injects instructions into the instruction stream 110 via the processor's injection bus 334. These injected instructions can flow through the instruction stream 110 and be executed by the execution units 106, or (depending on the configuration of the instructions) can flow through the execution units 106 to the load store units 108. As described above, to be eligible for instruction injection, the active stride load matching the branch is associated with a confidence level that meets a first threshold confidence level (e.g., is greater than or equal to a threshold accuracy), and the conditional branch is also associated with a confidence level that meets a second threshold. Additionally or alternatively, eligibility for instruction injection is based on whether at least one load dependent branch matching the active stride load is associated with an accuracy level that meets a threshold accuracy (e.g., is less than a threshold accuracy), where the accuracy level is indicated in the prediction accuracy field 328 of the entry associated with the load dependent branch.

[0071] In response to identifying a qualified stride load driven branch pair, the branch detector 302 is configured to operate in an insertion mode. In the insertion mode, the branch detector 302 inserts an instruction 336 via the injection bus 334 to fetch the data of the future load instruction. The injected instruction 336 uses the address of the active stride load offset by a distance based on its corresponding step size indicated in the stride field 314 of the table 304. In one example, the data of the future load instruction is written to at least a portion of a temporary register (not shown) or location of the processor. In one or more embodiments, the temporary register number of this temporary register is included in the stride load register number field 322 of the table 304. The temporary register is accessible to the decode unit 104 and / or the branch detector 302.

[0072] According to the described technique, the branch detector 302 inserts an additional instruction 338 via an injection bus 334. The additional instruction 338 is configured according to each conditional branch instruction determined to be dependent on the identified active stride load. The additional instruction 338 is further configured to include data of the future load (of the active stride load), for example, in place of the source register 332 indicated in the respective branch instruction 326. The execution unit 106 receives the additional instruction 338 and uses the additional instruction 338 to pre-calculate the outcome of each load-dependent branch having a prediction accuracy 328 that meets (e.g., is equal to or less than) the prediction accuracy threshold. In at least one example, the execution unit 106 pre-calculates the outcome of the load-dependent branch according to the additional instruction 338 and does not set an architectural flag. This precludes the processing of any temporary flag in some scenarios. In one or more embodiments, the system and / or the execution unit 106 includes a branch comparison unit 340 that pre-calculates the outcome of the future load-dependent branch. Alternatively, the branch compare unit 340 receives pre-computed results of load-dependent branches, for example from the execution unit 106 .

[0073] The pre-computed outcome of the load dependency branch (e.g., whether the branch is taken or not taken) is communicated to a table 308 accessible to the branch predictor 136, e.g., table 308 is maintained in the branch predictor 136. In one or more embodiments, table 308 includes one or more entries having a valid field 342, an identifier field 344, a pre-computed branch outcome field 346, and a pre-fetch distance field 348. It should be understood that table 308 may be configured differently, e.g., have different fields, in one or more variants.

[0074] In accordance with the described techniques, the precomputed branch result field 346 is updated (e.g., by the branch compare unit 340) to include the above-mentioned precomputed results for the entries corresponding to the respective branches. As an example, the precomputed result of a load-dependent branch indicates that the branch is taken. In this scenario, the precomputed branch result field 346 is populated with an indicator (e.g., a value) that indicates that the branch is taken. In an alternative example, the precomputed result of a load-dependent branch indicates that the branch is not taken. In this alternative scenario, the precomputed branch result field 346 is populated with an indicator (e.g., a value) that indicates that the branch is not taken.

[0075] Using the precomputed branch results from table 308, branch predictor 136 improves its prediction result. Consider a first example where branch predictor 136 has not yet reached a future iteration of a load-dependent branch corresponding to an entry in table 308. In this first example, branch predictor 136 uses the precomputed result (branch taken) instead of the predicted result, and instructions are speculatively executed based on the precomputed result. The speculatively executed instructions (executed based on the precomputed result) are more likely to be usable than instructions speculatively executed based on the predicted result of a conditional branch instruction that has low prediction accuracy 328.

[0076] Also consider a second example where the branch predictor 136 has already passed an iteration of a load-dependent branch that corresponds to an entry in the table 308. This occurs, for example, when a precomputed result is not yet available in the table 308 and an instruction is speculatively executed based on a precomputed result of a conditional branch instruction (which has low prediction accuracy 328). In this second example, the branch predictor 136 can perform an early redirection that saves many cycles for redirection from the execution unit 106. This improves the processor's performance in both the first and second examples.

[0077] FIG. 4 illustrates a procedure 400 in an exemplary embodiment for injecting instructions into a processor's instruction stream to fetch data for a future load instruction.

[0078] Detecting a load-dependent branch instruction by identifying that a destination location of the load instruction is used in an operation to determine whether a conditional branch is taken or not taken, the load instruction being included in a sequence of load instructions having addresses separated by a step size (block 402). For example, a conditional branch is a compare operation immediately followed by a conditional jump instruction. In one example, the branch detector 302 detects a load-dependent branch instruction as corresponding to a branch instruction 326 that uses a destination location included in a destination register field 318 of the table 304 in a source register field 332.

[0079] An instruction is injected into the processor's instruction stream to fetch data for the future load instruction using the address of the load instruction offset by a distance based on the step size (block 404). For example, branch detector 302 injects instruction 336 via injection bus 334 to fetch data for the future load instruction in instruction stream 110.

[0080] FIG. 5 illustrates a procedure 500 in an exemplary embodiment for injecting instructions into a processor's instruction stream to pre-compute the outcome of a load-dependent branch.

[0081] A load dependent branch instruction is detected (block 502) by identifying that the destination location of the load instruction is used in an operation to determine whether the conditional branch is taken or not taken. In accordance with principles described herein, the load instruction is included in a sequence of load instructions having addresses separated by a step size. As an example, a conditional branch is a compare operation immediately followed by a conditional jump instruction. Branch detector 302 also detects load dependent branch instructions using branch instructions 326.

[0082] An instruction is injected into the processor's instruction stream to pre-calculate the outcome of the load-dependent branch based on the address of the operation and the data of the future load instruction fetched using the step size (block 504). The instruction may, for example, use the data of the future load instruction. In one example, the branch detector 302 injects an additional instruction 338 into the instruction stream 110 via injection bus 334.

[0083] It should be understood that many variations are possible based on the disclosure herein, and although features and elements are described above in specific combinations, each feature or element can be used alone without the other features and elements, or in various combinations with or without the other features and elements.

[0084] The various functional units illustrated in the figures and / or described herein (including, where appropriate, the decode unit 104, the execution unit 106, the load store unit 108, the branch predictor 136, the stride prefetcher 122, the branch detector 302, and the branch compare unit 340) may be implemented in any of a variety of different manners, such as hardware circuits, software or firmware running on a programmable processor, or any combination of two or more of hardware, software, and firmware. The methods provided may be performed in any of a variety of devices, such as a general purpose computer, a processor, or a processor core. Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a Graphics Processing Unit (GPU), an Accelerated Processing Unit (APU), a parallel accelerated processor, multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (PGA) circuit, any other type of Integrated Circuit (IC), and / or a state machine.

[0085] In one or more embodiments, the methods and procedures provided herein are implemented in a computer program, software, or firmware embodied in a non-transitory computer-readable storage medium for execution by a general purpose computer or processor. Examples of non-transitory computer-readable storage media include read only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs).

Claims

1. 1. A method comprising: Detecting a load dependent branch instruction by identifying a destination location of a load instruction used in an operation to determine whether a conditional branch is taken or not taken, the load instruction being included in a sequence of load instructions having addresses separated by a step size; injecting instructions into the processor's instruction stream to fetch data for a future load instruction using the address of the load instruction offset by a distance based on the step size; method.

2. and injecting an additional instruction into the instruction stream to pre-calculate a result of a load-dependent branch using an address calculated based on the address of the operation and data of the future load instruction.

2. The method of claim 1.

3. and writing the resulting indicator into a pre-computed branch table. The method of claim 2.

4. the load dependency branch instruction is detected in a decode unit of the instruction stream; 2. The method of claim 1.

5. The distance is the product of the step size and the number of steps.

2. The method of claim 1.

6. the instructions are injected into the instruction stream via an injection bus of the processor; 2. The method of claim 1.

7. storing data of the future load instruction in a temporary register or location accessible to a decode unit of the processor.

2. The method of claim 1.

8. the operation is a comparison operation, and the load-dependent branch instruction is detected based on a prediction accuracy of the conditional branch.

2. The method of claim 1.

9. The load dependent branch instruction is detected based on a confidence level of the load instruction.

2. The method of claim 1.

10. 1. A system comprising: a decode unit of a processor configured to identify a destination location of a load instruction for use in an operation to determine whether a conditional branch is taken or not taken, the load instruction being included in a sequence of load instructions having addresses separated by a step size; a branch detector of the processor configured to inject instructions into an instruction stream of the processor to fetch data for a future load instruction using an address of the load instruction offset by a distance based on the step size. system.

11. the branch detector is configured to inject additional instructions into the instruction stream to pre-calculate an outcome of a load-dependent branch using an address calculated based on the address of the operation and data of the future load instruction; The system of claim 10.

12. an execution unit of the processor configured to write the resulting indicator into a pre-computed branch table; The system of claim 11.

13. data for the future load instruction is stored in a temporary register or location accessible to the decode unit; The system of claim 10.

14. The distance is the product of the step size and the number of steps. The system of claim 10.

15. the instructions are injected into the instruction stream via an injection bus of the processor; The system of claim 10.

16. 1. A method comprising: Detecting a load dependent branch instruction by identifying a destination location of a load instruction used in an operation to determine whether a conditional branch is taken or not taken, the load instruction being included in a sequence of load instructions having addresses separated by a step size; injecting instructions into the instruction stream of the processor to pre-calculate an outcome of a load-dependent branch based on the address of the operation and data of a future load instruction fetched using the step size; method.

17. data for the future load instruction is fetched using the address of the load instruction offset by a distance based on the step size; 17. The method of claim 16.

18. storing data of the future load instruction in a temporary register or location accessible to a decode unit of the processor.

20. The method of claim 17.

19. and writing the resulting indicator into a pre-computed branch table.

17. The method of claim 16.

20. the operation is a comparison operation, and the load-dependent branch instruction is detected based on a prediction accuracy of the conditional branch.

17. The method of claim 16.

Images