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