Dynamic Branch Prediction for a VLIW Processor

Transcription

1 Dynamic Branch Prediction for a VLIW Processor Jan Hoogerbrugge Philips Research Laboratories, Prof. Holstlaan 4, 5656 AA Eindhoven, The Netherlands Abstract This paper describes the design of a dynamic branch predictor for a VLIW processor. The developed branch predictor predicts the direction of a branch, i.e., taken or not taken, and in the case of taken prediction it also predicts the issue-slot that contains the taken branch. This information is used to perform the BTB lookup. We compare this method against a typical superscalar branch predictor and against a branch predictor developed for VLIWs by Intel and HP. For a 2K entry BHT, 512 entry BTB, gshare branch predictor we obtain a next pc misprediction rate of 7.83%, while a traditional superscalar-type branch predictor of comparable costs achieves 10.3% and the Intel/HP predictor achieves 9.31%. In addition, we propose to have both predicted and delayed branches in the ISA and let the compiler select which type to apply. Simulations show performance improvements of 2-7% for benchmarks that are well-known for their high misprediction rates. This paper also contributes an experiment to determine whether speculative update in the fetch stage and correction of mispredictions is really necessary for VLIWs, instead of updating when branches are resolved. Experiments show that the performance advantage of speculative updating is small. 1. Introduction Dynamic branch prediction is usually associated with dynamically scheduled superscalar processors and not directly with statically scheduled very long instruction word (VLIW) processors. In fact, most VLIWs have delayed branches instead of dynamic branch prediction. The compiler is responsible for filling delay slots often assisted by static branch prediction based on profiling. As can be expected, dynamic branch prediction is applicable for VLIWs. It is useful in the cases where a compiler has difficulties with filling branch delay slots. Nevertheless, while investigating dynamic branch prediction for our target VLIW, the TriMedia processor, we encountered two problems. First, when multiple conditional direct branches are scheduled in one VLIW instruction, the instruction becomes a multi-way branch with multiple branch targets. This does not work well for traditional BTBs (branch target buffers) which associate only one branch target address with an instruction address. Second, in many cases, delayed branches are more preferable than predicted branches, when delay slots can be filled effectively and/or the branch is hard to predict. Both problems are addressed in this paper. The solutions that we propose for the two encountered problems are: First, in addition to predicting the branch direction, i.e., taken or not taken, we also predict which issue-slot contains the taken branch. This issue-slot information is used for the BTB lookup. The BTB now associates a branch target address with the combination of instruction address and issueslot. Second, we provide both delayed branches and predicted branches in the ISA. The compiler selects between those types based on how well it is able to fill delay slots and the expected branch prediction accuracy. The paper is organised as follows. Section 2 gives background information on dynamic branch prediction. Section 3 describes the simulation environment and benchmarks that we used. Section 4 discusses branch prediction for VLIWs based on issue-slot prediction. Section 5 describes how delayed and predicted branches can be used to improve performance. Section 6 discusses whether speculative update of the branch predictor is necessary. Finally, section 7 gives the conclusions. 2. Background Dynamic branch prediction is typically implemented using two structures: the BTB (branch target buffer) and the BHT (branch history table). The BTB detects branches and predicts branch targets, while the BHT predicts the branch direction. The BTB The BTB is a cache where instruction addresses are associated with branch targets [11]. If an instruction address hits in the BTB, we know that it is the address of a branch instruction and we have a prediction for its branch 1

2 N SN 00 T T T WN WT N N N Predict not taken Predict taken ST 11 T current pc br. hist. XOR index index tag BHT BTB incr. RAS Figure 1. State diagram for direction prediction based on two bit saturating counters. direction hit type target next instr. next pc selection ret. addr. next pc target. This branch target is the branch target of the last execution of the branch. This usually works very well since most branches are direct branches with a static branch target. This is not the case for indirect branches. Many of the indirect branches are function returns. The prediction of function returns can be improved by maintaining a return address stack (RAS) [8]. Function call branches push the return address on the RAS and function return branches pop values of the RAS. To determine the branch type, which is necessary to detect function returns in the fetch stage, the BTB usually also associates type information with instruction addresses. Alternatively, type information can be predecoded in the instruction cache. The BHT The BHT predicts the direction of conditional branches, i.e., whether a branch is taken or not. This is typically implemented by a table of two bit saturating counters indexed by the lower part of the pc [18]. Such a counter is incremented when a resolved branch is taken and is decremented when it is not taken. A branch is predicted as taken if the most significant bit of the corresponding two bit counter is set. The four states of the two bit counter have the following names: 0 = strongly not taken (SN), 1 = weakly not taken (WN), 2 = weakly taken, and 3 = strongly taken (ST). Figure 1 shows the state diagram corresponding to the two bit counter. The rationale for weak and strong states is to introduce some form of hysteresis in the branch predictor. Whenever a branch that is biased in one direction is mispredicted, we should give it a second chance before changing the prediction. This is realised by moving from a strong to a weak state, but maintaining the same prediction. Whenever we mispredict the branch again, we change our prediction. In the case of a correct prediction, we move back to the strong state. Because BHTs are tag-less tables, conflicts of mapping multiple branches onto the same counter are not detected. This is known as aliasing. Aliasing reduces prediction accuracy. A lot of research has been performed in the last decade to improve the branch prediction accuracy. Probably the most important invention has been the exploitation of correlation between branch directions [20, 15] in the so-called two-level adaptive schemes. Global schemes have a branch Figure 2. A gshare branch predictor [12] consisting of a BTB, BHT, and RAS. history register, that is a shift register into which directions of resolved conditional branches are shifted. The content of the branch history register is combined with the lower part of the pc to access the table of two bit counters. This achieves correlation exploitation between successively executed branches. Combining the branch history register and the lower part of the pc can be done by concatenating them, as is done in the GAs and GAp schemes, or XORing them, as done in the gshare scheme [12]. Per-branch schemes, also called local schemes, associate a branch history register to a branch. Such a register records the outcomes of the last executions of the corresponding branch. One can view this as the rhythm of a branch. This rhythm, possibly combined with the pc, is mapped by a table of two bit counters on a prediction. For example, a branch with history TTTNTTTNT (T = taken, N = not taken) will probably to be predicted as being taken since it is not-taken every four executions. Combining BTB, BHT, and RAS results Figure 2 shows how the BTB, BHT, and RAS are combined to implement a gshare branch predictor [12]. The current pc is used to access the BTB and BHT. The pc is XORed with the branch history register to achieve branch correlation exploitation. The results of the BTB and BHT lookups are combined in the following way to predict the next pc: if (BTB missed) next pc = pc + size of instruction else if (BTB type is return) next pc = top of RAS else if (BTB type is cond. branch && BHT predicts taken) next pc = target returned by BTB else next pc = pc + size of instruction 3. Simulation Environment and Benchmarks We used the compiler and simulation environment of the Philips TriMedia TM1000 VLIW mediaprocessor for 2

3 our experiments. The TriMedia TM1000 is a five issueslot VLIW with three issue-slots in which branches can be scheduled. Branches are resolved in the first execute stage that is the fourth pipeline stage. This leads to three branch delay slots, i.e., three instructions following a taken branch are executed before the branch takes place. For our experiments, we use 10 benchmarks from SPECint92 and SPECint95. Simulation is limited to 20 million branch containing instructions. The total number of simulated instructions is typically a few times more and the total number of simulated instructions is again a few times more. Due to technical difficulties, we are not able to simulate caching effects in combination with branch prediction. This is only relevant in section 5 where we present execution times instead of misprediction rates. The benchmarks are compiled with the TriMedia version 2.0 production compiler with optimization level -O3 [6]. This level includes loop unrolling and if-conversion, which transforms branches into guarded execution in order to reduce branches. Sophisticated scheduling techniques are employed to fill branch delay slots [6]. Except for the experiments described in section 5, compiler optimizations do not take branch mispredictions into consideration. Handling mispredictions for a VLIW is less complex than it is for a superscalar, where dynamic speculative execution is employed. In the case of a misprediction which is detected in the fourth pipeline stage, the first three pipeline stages are flushed and are refilled with instructions from the correct position. During this, the fourth stage and the stages that follow it are frozen. This is to ensure that the resource requirements pattern (i.e., when resources are used) of an operation used by the instruction scheduler is not affected by dynamic events. Alternatively, one can flush the pipeline and start refilling when no resource conflicts can occur anymore between operations before and after the mispredicted branch. 4. Dynamic Branch Prediction Based on Issue- Slot Prediction 4.1. Problem statement Existing branch predictors known from the literature, of which the one described in section 2 is a typical example, are designed for sequential ISAs. These predictors do not perform well for VLIWs where multiple branches can be scheduled in one instruction. Results shown in table 1 show that the scheduler actually schedules multiple branches per cycle on control-flow intensive code. It shows that many instructions that contain branch operations contain multiple branch operations; on average more than one third. The problem is that the BTB does not work effectively anymore because a BTB can associate only one branch target and Benchmark Branches per instruction espresso li eqntott compress sc gcc go m88ksim ijpeg perl Average Table 1. Distribution of branches per instruction branch type to an instruction address. The following sequential code of three conditional branches illustrates the problem: br (x=1) L1; br (x=2) L2; br (x=3) L3; After this sequential code has been executed with values 1, 2, and 3 for x, all three branches are stored in the BTB. From that moment on all BTB accesses will be hits and will deliver the correct target. The only branch mispredictions are caused by imperfections of the BHT. Now consider what will happen when all three branches are scheduled into one VLIW instruction: br (x=1) L1, br (x=2) L2, br (x=3) L3; We now no longer have the situation where all BTB accesses deliver the correct target, because the VLIW instruction has three targets. Consider the case where the example VLIW instruction is repeatedly executed with different values for x, either 1, 2, or 3. All mispredictions in the scalar machine were caused by the BHT. In the VLIW case the instruction is always taken but with different targets. Therefore, all mispredictions are caused by the BTB. We have the feeling that this shift of the causes of misprediction from the BHT to the BTB is typical. We could improve the BTB target prediction accuracy by a gshare kind of technique, which has also been proposed to predict indirect branches [2]. Unfortunately, gshare would make more BTB entries necessary; these are wide and thus expensive. Therefore, we tried to solve the problem in another way, using issue-slot based prediction, which is described in the next section Issue-slot based branch prediction Our solution to the problem described in section 4.1 is to predict not only the direction of the branch, but also the 3

4 SN S1 Predict WN W1 Predict Not taken Taken slot 1 current pc br. hist. XOR index index tag BHT tag BTB incr. RAS issue slot hit type target next instr. ret. addr. Predict Predict Taken slot 2 Taken slot 3 W2 W3 direction next pc selection Figure 4. An issue-slot based predictor next pc S2 Figure 3. State diagram for issue-slot prediction. Dashed transitions are taken on mispredictions; solid transitions are taken on correct predictions. issue-slot that contains the taken branch, in the case that the predicted direction is taken. Therefore, for our TriMedia processor with three branch issue-slots, we predict either not taken, taken by slot 1, taken by slot 2, or taken by slot 3. The prediction is made in a similar way to a directiononly prediction. A state machine is introduced with two states for every prediction outcome: a strong and a weak one. The state diagram is shown in figure 3. The state machine no longer corresponds to a saturating counter. This is obviously not a problem. The direction and issue-slot predicted by the BHT is used to perform the BTB lookup. The BTB associates a branch target and type information with a combination of an instruction address and issue-slot. For direct branches this information is constant for each combination of an instruction address and issue-slot. This means that the BTB performs as it used to do. We implement the association with the combination of instruction address and issue-slot by extending the tags of the BTB with an issue-slot identifier; two bits in our case. The issue-slot identifier is not used to index (i.e. address) the BTB, however. This would create a potential cycle time problem, since the BHT and BTB would have to be accessed sequentially. Figure 4 shows the organisation of the branch predictor. The following differences can be seen when compared to figure 2: the information delivered by the BHT is different, information is passed from the BHT to the BTB, and the tags of the BTB are extended. The function of the branch history register has also been changed. Instead of shifting in one bit representing the direction of a resolved branch, we now shift in two bits corresponding to one of four results: not taken and taken by one of the three branch issue-slots. The same applies for per-branch two-level adaptive schemes. No shifting takes place when the instruction does not contain branches. The disadvantage of shifting in issue-slot information instead of direction information only is that it takes more space and S3 therefore the history is less deep. However, more information is recorded per branch instruction. We experimented with both schemes to capture history information and came to the conclusion that recording issue-slot information gives the best results. The state machine used for issue-slot prediction is very similar to the state machine proposed by Menezes et. al for path prediction [13]. A path predictor predicts the outcomes of several successive branches in a single prediction [3, 16]. To evaluate our ideas we compared the system shown in figure 2 with the system shown in figure 4. We used a 2K entry BHT, a 512 entry, 4 way set-associative BTB with LRU replacement, and a 32 entry RAS. We used a 12 bit branch history register for gshare. These numbers are typical for contemporary microprocessors. The first two sets of three columns of table 2 show the results. The three columns show the BHT misprediction rate (wrong direction or issues-slot prediction), the BTB misprediction rate (wrong target given correct direction or issue-slot prediction), and the total misprediction rate (wrong next pc prediction). The high BTB misprediction rate, relative to the BHT misprediction rate confirms the feeling that we described in section 4.1. In comparison to direction prediction, issue-slot based branch prediction has a higher BHT misprediction rate (5.31% vs. 6.62%) because more information is predicted, but the BTB misprediction rate is much lower (5.94% vs. 1.97%). The total next pc misprediction rate is reduced from 10.3% to 7.83%. The improvement comes at the price of wider BHT and BTB entries. The BHT entries have been extended by one bit for issue-slot prediction. The BTB entries have been extended by 2 tag bits for issue-slot identifiers. The total size increased from 4.6KBytes to 5.1KBytes Comparison with multi-target BTBs An alternative solution to the problem described in section 4.1 are multi-target BTBs, which are patented by Intel and HP in US Patent 5,903,750 [21]. In this solution, the BTB entries have multiple branch targets; one for each branch issue-slot. The issue-slot prediction is used to select one of the targets. Multi-target BTBs differ from our proposed system of single-target BTBs with issue-slot tags 4

5 Benchmark Direction prediction Direction and issue-slot prediction Single-target BTB Multi-target BTB dir. target total slot target total slot target total 008.espresso li eqntott compress sc gcc go m88ksim ijpeg perl Average Table 2. Misprediction rates for three different types of branch predictors. Three numbers are given for every type. The misprediction rate of the BHT, i.e., the rate of predicting the wrong direction or issue-slot in the case of issue-slot prediction is given first. Then, the misprediction rate of the BTB in case of a correct prediction by the BHT is given. Finally, the combined misprediction rate of the branch prediction system is given. in storage efficiency. Which one is more efficient depends on the number of active branches per instruction, where an active branch is a branch that is often taken. When there are many active branches per instruction, a multi-target BTB is more efficient since the tag is shared by multiple branches. When there are few active branches per instruction, on the other hand, a multi-target BTB is less efficient since most of the branch target fields are not used. We implemented multi-target BTBs in our simulator to compare both schemes. For comparison we use a multi-target BTB with 256 entries, since a multi-target BTB entry is about twice as wide as a single-target BTB entry for a three branch issueslot configuration 1.Both BTBs, a 256-entry multi-target and a 512-entry single target, have therefore approximately the same cost in terms of die area. The remaining parameters, including set-associativity of the BTB, remain the same. The last set of three columns of table 2 lists the results. It is obvious that the BHT misprediction rate has not changed with respect to single-target issue-slot based branch prediction. The BTB misprediction rate is clearly higher for multi-target BTBs (1.97% vs. 3.44%) and therefore also the total next pc misprediction rate (7.83% vs. 9.31%). This makes single-target BTBs more favourable than multi-target BTBs Compatibility with other techniques The usefulness of a technique, in our case branch prediction based on issue-slot prediction, depends also on how 1 A single-target BTB entry consists of one tag and one target; a multitarget BTB entry consists of one tag and three targets (in this case). In the case full resolution a multi-target BTB entry is therefore approximately twice as wide as a single-target entry, e.g., ( ) vs. (20+30). well it can be combined with other techniques. In this section we describe whether our technique is compatible with several other existing techniques. Combination with variants of two-level adaptive branch predictors other than gshare is possible [20, 15]. Using Yeh and Patt s terminology, the two bit counters in the pattern history table (PHT) have to be replaced by a state of a state machine as shown in figure 3. The branch history table/register (BHT/BHR) is changed such that issue-slot information is shifted in it instead of only direction information. In this paper we described our ideas for three branch issue-slots, however, it is straightforward to generalize this. For Ò branch issue-slots, the PHT entries are ½ ÐÓ ¾ Ò ½µ bits wide and ÐÓ ¾ Ò ½µ bits of history information is produced per branch containing instruction. Hybrid branch predictors [12] also pose no problems. A meta predictor selects between the direction and issue-slot predictions of several predictors. Several techniques exist that attempt to reduce the negative effect of aliasing in the BHT: the agree predictor [19], the filter predictor [1], the skewed predictor [14], the bimode predictor [9], and YAGS [4]. Two of them pose problems: the agree predictor and the filter predictor. Both pass information from the BTB to the BHT. Since we pass information in the opposite direction, we have a dependence cycle between the BTB and BHT. This makes the agree and filter predictors incompatible. Fortunately, comparisons between the five techniques described in [10, 4] indicate that the agree and filter predictor are the least accurate of the five predictors. 5

6 5. Selective Dynamic Branch Prediction VLIW processors typically expose micro-architectural details in their ISA that superscalar processors hide. VLIW processors expose them so that a compiler can make use of them, while superscalars hide them to maintain object code compatibility between different implementations of the same architecture. The micro-architectural feature related to this paper is the number of stages in front of the stage in which branches are resolved. This can be exposed by means of delayed branches and effectively hidden by means of branch prediction. When we have the opportunity to expose micro-architectural details, we can provide both delayed branches as well as predicted branches in the ISA. The compiler can then select between both types by using different opcodes. Delayed branches are used when delay slots can be filled effectively and/or branches are hard to predict. An additional advantage of this idea, which we call selective dynamic branch prediction, is that delayed branches do not need the BHT and BTB and therefore do not update them. This reduces the pressure on them, which makes smaller tables possible. Delayed branches are still updating the branch history register, however, or the branch history table in the case of per-address schemes, in order to improve prediction accuracy of predicted branches via branch correlation. Delayed branches also update the RAS because functions are compiled independently of each other and a caller does not know whether the callee will return via a predicted branch or a delayed branch. In fact, a function can have multiple returns of different types. We implemented selective dynamic branch prediction in our compiler and simulator. The selection is made with decision tree granularity. Decision trees are the scheduling units used by our compiler [6]. All branches in a decision tree are either delayed branches or predicted branches. Selecting branch types on a finer granularity will require more effort in the compiler and will be complex in hardware or will be constrained by scheduling rules. Such a rule might be that predicted branches are not allowed to be scheduled in delay slots of delayed branches because mispredictions in delay slots cannot be handled. The implementation in our compiler is as follows. Prior to scheduling a decision tree, the compiler selects between the branch types for that particular decision tree. This is done by estimating the schedule length that it will obtain for each of the two types. The schedule length is estimated by scheduling the decision tree by a simple and fast scheduler which is far less sophisticated than the actual scheduler. The simple scheduler does not check all resource constraints for this estimation, e.g., available write back buses, and it does not perform integrated register allocation [6]. In the case of delayed branches, the estimated execution time corresponds to the estimated schedule length (cache effects are ignored). In the case of predicted branches, the estimated execution time is computed by multiplying the estimated schedule length by an estimated branch misprediction penalty. We currently use 1.08 as branch misprediction penalty estimation, which is determined empirically. Table 3 lists the outcomes of measurements to evaluate selective dynamic branch prediction. We used a branch misprediction penalty of 4 cycles for these experiments. The first column shows the performance improvements of predicted branches over delayed branches. There is a large variation in improvements among the benchmarks. The only benchmark that performs worse is go. The reason is obviously its high misprediction rate (21%). The next column pair shows results for selective dynamic branch prediction. This turns out to be effective for go, which now performs slightly better than using only delayed branches. On average, the performance improvement is slightly negative. This is mainly caused by eqntott, where the heuristic value of 1.08 is a bad choice. We can improve this by performing a profile run to measure mispredictions. This makes a better selection between branch types possible. The results are shown in the last column pair. In comparison with predicted branches only, the performance improved by almost 2%. Although this might seem low, it is most effective for the benchmarks that suffer from a high misprediction rate such as gcc, go, and perl. Table 3 also lists the percentage of dynamic delayed branches, which is 33% on average. This is an indication of the reduction in table pressure. 6. The Necessity of Speculative Update In previous sections we did not discuss when the branch predictor is updated. We assumed that all previously executed branches update the branch predictor before a new prediction is made. This is not true in an instruction pipeline, where branch instructions can be in-flight between the fetch stage where prediction takes place, and the pipeline stage where branches are resolved. The result is that the outcomes of the last few branches have not updated the predictor. The effect is most severe in deeply pipelined machines. Another effect occurring only in out-of-order superscalar processors is that the order in which branches are resolved and update the global branch history register varies because of dynamic events such as cache misses. Both effects make branch correlation less effective. Several researchers identified this problem [5, 7, 17] and proposed to update the branch predictor speculatively in the fetch stage and correct the branch predictor on a misprediction. This complicates the design of the branch predictor and may affect the cycle time. The time between fetching and resolving branches is typically shorter for VLIWs than for superscalars. This is 6

7 Benchmark Predicted Mixed Mixed with feedback performance performance frac. delayed performance frac. delayed 008.espresso li eqntott compress sc gcc go m88ksim ijpeg perl Average Table 3. Performance relative to delayed branches in three cases: 1) predicted branches only, 2) mixing predicted and delayed branches, and 3) mixing predicted and delayed branches employing profile feedback information. In the case of profile feedback, we use the same input data for profiling as well as for the actual measurement. because there are no pipeline stages needed, for example, for register renaming, and instructions are not delayed in buffers and reservation stations. Furthermore, the second effect, varying resolve order, does not apply for VLIWs. It therefore makes sense to ask ourselves whether speculative update is necessary in our case. To answer this question we modelled an instruction pipeline in our simulator where the branch predictor is updated in the fourth pipeline stage. Branches in the second, third, and also the fourth pipeline stage are not used for prediction in the fetch pipeline stage. Table 4 lists the result of a measurement that compares speculative update against resolve-time update. It includes the average number of updates that are missing for predicting the currently being fetched instruction. For resolve-time update this number corresponds to the number of branch containing instructions that are in-flight between the first and fourth stage. For speculative update it is obviously zero. The results show that the effect of speculative update is small (7.83% vs. 8.43%) and could be omitted to reduce hardware complexity. The results show that both the issue-slot prediction as well as the branch target prediction are less accurate when speculative update is not applied. The former can be explained by less effective exploitation of branch correlation; the most recent branches which are most correlated are missing. The latter can be explained by rapidly following function return branches, where the top of stack pointer has not been updated before the next function return branch is fetched. It also occurs when a function call branch is rapidly followed by a function return branch, where the function return branch is fetched before the function call updated the RAS by pushing the return address on it. 7. Conclusions This paper described branch prediction for VLIWs. We have shown that a branch prediction specially designed for VLIWs gives better results than the application of a branch predictor that is typically found in superscalar processors. In the proposed branch predictor, both the direction (taken or not taken) and the issue-slot containing the taken branch is predicted. This information is used to perform the BTB lookup. The BTB associates target and type information with the combination of an instruction address and issueslot. We have also shown that this system performs better than multi-target BTBs which have been proposed before. Furthermore, we identified the possibility of mixing predicted and delayed branches in an ISA. The compiler has to select between those types. This gave clear performance improvements for benchmarks which suffer from a high misprediction rate. Finally, we measured whether a speculative update of the branch predictor in the fetch stage and correcting it on a misprediction is really necessary for our target VLIW, the TriMedia. Measurements show that the effects are small. References [1] P.-Y. Chang, M. Evers, and Y. N. Patt. Improving Branch Prediction Accuracy by Reducing Pattern History Table Interference. In Proceedings of the 1996 Conference on Parallel Architectures and Compilation Techniques (PACT 96), pages 48 57, Boston, Massachusetts, October 20 23, [2] P.-Y. Chang, E. Hao, and Y. N. Patt. Target Prediction for Indirect Jumps. In Proceedings of the 24th International Symposium on Computer Architecture, Denver, June [3] S. Dutta and M. Franklin. Control Flow Predication with Tree-Like Subgraphs for Superscalar Processors. In Pro- 7

8 Benchmark Speculative update Resolve-time update slot target total missing slot target total missing miss rate miss rate miss rate updates miss rate miss rate miss rate updates 008.espresso li eqntott compress sc gcc go m88ksim ijpeg perl Average Table 4. Speculative update vs. resolve-time update. The first three columns correspond to the columns of table 2. The fourth column lists the number of updates that are missing on average due to pipeline effects. ceedings of the 28th Annual International Workshop on Microprogramming, pages , Ann Arbor, Michigan, Nov [4] A. N. Eden and T. Mudge. The YAGS Branch Predictor. In Proceedings of the 31th Annual International Symposium on Microarchitecture, pages 69 77, Dallas, Texas, Nov [5] E. Hao, P.-Y. Chang, and Y. N. Patt. The Effect of Speculatively Updating Branch History on Branch Prediction Accuracy, Revisited. In Proceedings of the 27th Annual International Symposium on Microarchitecture, pages , San Jose, California, November 30 December 2, [6] J. Hoogerbrugge and L. Augusteijn. Instruction Scheduling for TriMedia. Journal of Instruction-Level Parallelism, 1(1), Feb [7] S. Jourdan, J. Stark, T.-H. Hsing, and Y. N. Patt. Recovery Requirements of Branch Prediction and Storage Structures in the Presence of Mispredicted-Path Execution. International Journal of Parallel Programming, 25(5): , Oct [8] D. R. Kaeli and P. G. Emma. Branch History Table Prediction of Moving Target Branches Due to Subroutine Returns. In Proceedings of the 18th Annual International Symposium on Computer Architecture, pages 34 42, Toronto, Ontario, May 27 30, [9] C.-C. Lee, I.-C. K. Chen, and T. Mudge. The Bi-Mode Branch Predictor. In Proceedings of the 30th Annual International Symposium on Microarchitecture, pages 4 13, Research Triangle Park, North Carolina, Nov [10] C.-C. Lee, I.-C. K. Chen, and T. Mudge. Design and Performance Evaluation of Global History Dynamic Branch Predictors. In Proceedings of the World Multiconference on Systemics Cybernetics and Informatics, SCI 98, pages , Orlando, FL, July [11] J. K. F. Lee and A. J. Smith. Branch Prediction Strategies and Branch Target Buffer Design. IEEE Micro, 21(7):6 22, Jan [12] S. McFarling. Combining Branch Predictors. Technical Report TN-36, Western Research Laboratory, Palo Alto, California, June [13] K. N. P. Menezes, S. A. Sathaye, and T. M. Conte. Path prediction for high issue-rate processors. In Proceedings of the 1997 Conference on Parallel Architectures and Compilation Techniques (PACT 97), San Francisco, CA, Nov [14] P. Michaud, A. Seznec, and R. Uhlig. Trading Conflict and Capacity Aliasing in Conditional Branch Predictors. In Proceedings of the 24th International Symposium on Computer Architecture, Denver, June [15] S.-T. Pan, K. So, and J. T. Rahmeh. Improving the Accuracy of Dynamic Branch Prediction Using Branch Correlation. In Proceedings of the Fifth International Conference on Architectural Support for Programming Languages and Operating Systems, pages 76 84, Boston, Massachusetts, October 12 15, [16] D. N. Pnevmatikatos, M. Franklin, and G. S. Sohi. Control Flow Prediction for Dynamic ILP Processors. In Proceedings of the 26th Annual International Workshop on Microprogramming, pages , Austin, Texas, Dec [17] K. Skadron, M. Martonosi, and D. W. Clark. Speculative Updates of Local and Global Branch History: A Quantitative Analysis. Journal of Instruction-level Parallelism, 2, Jan [18] J. E. Smith. A Study of Branch Prediction Strategies. In Proceedings of the 8th Annual International Symposium on Computer Architecture, pages , May [19] E. Sprangle, R. S. Chappell, M. Alsup, and Y. N. Patt. The Agree Predictor: A Mechanism for Reducing Negative Branch History Interference. In Proceedings of the 24th International Symposium on Computer Architecture, Denver, June [20] T.-Y. Yeh and Y. N. Patt. Two-Level Adaptive Training Branch Prediction. In Proceedings of the 24th Annual International Symposium on Microarchitecture, pages 51 61, Albuquerque, New Mexico, November 18 20, [21] T.-Y. Yeh, M. Poplingher, W. Chen, and H. Mulder. Dynamic Branch Prediction for Branch Instructions with Multiple Targets, May US Patent 5,903,750, Filed November 20,