High guys,

We just noticed some interesting behavior in the branch prediction infrastructure (bpred_unit.cc). I was wondering if some of you could shed light on it.

When a branch is mispredicted at execute, all younger branches in the history of branches are removed. Then, the predictor is updated with the actual direction (by calling update(squashed = true) ).

The history is marked as "wasSquashed", so that when it reaches commit, a second update does not take place (retireSquashed() is called, rather than update(), as a result of wasSquashed being true).

Now, you may know where I am going with this: in all branch predictors, the tables are updated when update(squashed = true) is called because there is no test against the value of squashed (except a fishy one in tournament.cc). This means that update is done speculatively at Execute, potentially on the *wrong path*. In other words, the predictor is potentially updated with garbage. What should be done is update the history with the actual direction at squash time, but *wait for commit to do the update*. As it stands, the more you do OoO on the wrong path, the worse branch prediction performance you get.

Now it is true that calling update() at squash time is useful if you want to fix whatever history you are using, and in that case, it is the responsibility of the predictor to test against the value of squashed in its update() function. However, the wasSquashed member and retireSquashed() function should probably be replaced by a call to update(squashed = false). What do you think?

Cheers,

Arthur.


_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to