Hi everybody. I'm reworking a lot of PC related stuff across CPUs and
ISAs (more to come soon) and I'm running into an assertion in the
branch predictor when running MIPS in O3. The assert is during a
squash when the branch that was mispredicted isn't the oldest pending
branch.
I don't have the code in front of my since I'm away from my
development machine, but I think the offending line is likely this one:
http://repo.m5sim.org/m5/file/c1b66fc648e2/src/cpu/o3/bpred_unit_impl.hh#l353
I looked at the instruction stream coming out of fetch and, again from
memory so don't hold me to specifics, the sequence that seems to cause
it is a jalr (sn:23) to a computed address in a register which is
unconditional but mispredicts as not taken since the target isn't
known, and then an unconditional branch (sn:25) which also doesn't
have a known target so is predicted as not taken but who's target I
think is resolved in decode.
The first branch, the jalr, is still winding its way to commit or
wherever its mispredict would be detected when the other branch is
detected as mispredicted in decode. Squash is called on the branch
predictor for this branch, sn:25, but sn:23 is at the head of the
prediction history. Kablooey.
I think this didn't happen with MIPS before because it would trick
fetch into thinking it was branching even when it didn't need to be
and it would space out the branches enough for everything to be worked
out. That matches the timing difference I saw in this early part of
the Exec trace, but I don't know if it's causal or just coincidence.
This sequence of events as described seems like an entirely plausible
thing to happen considering branches can be resolved out of order if
they're different types. Is the assert just too picky? Is there some
structural reason this would break the branch predictor? Will this
just "never happen" if some invariant I inadvertently violated was
still true? I think the assert is just too picky, but I want to hear
from the experts before I go trying to fix it.
Gabe
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
