This fixes a wedge in the frontend: the fetch stage could get stuck
in a loop, with the next address predictor deciding that the redirect
PC is a compressed instruction doing a close jump. On mispredict,
this would get retrained, but "mispedict" was denoted as an
untaken branch to PC+2. If unlucky, PC+2 could cross an alignment
boundary, causing the untaken branch to be interpreted as a long
branch, leaving an old competing entry in the compressed branch BTB,
which would then take priority.
Fix by always marking entries in both close and long BTBs when not
taken: to avoid hurting performance, this kind of update will not
insert into either BTB unless already present.
0ae1d8a275