Despite the name, we can end up having a pending_straddle at an "even"
PC (and thus an "odd" pc_start). In this case, we would erroneously
treat it as if pc_start were "even", effectively shifting all the
instruction parcels along by one and duplicating the first one, since
the first element of the parcels vector will be a copy of the straddle's
parcel itself. Instead, we should just ignore pending_straddle when
determining where to start in the parcels vector, as the two are
completely independent, and no longer hard-code that the straddle is
merged with element 0.
This can happen if we predict that the first half of an uncompressed
instruction is a taken branch. We will have the instruction bytes
available, but not the prediction information, so still have to do a
normal Fetch3 redirect in the same manner as an unaligned uncompressed
instruction. We could perhaps special-case with a fast-path (or query
the predictor directly in Fetch3), but it should hit in the TLB and L1
cache, and is probably not common enough to warrant the complexity.
The FreeRTOS-based netboot loader trips up on this as it overwrites
itself with the payload, and thus all the branch prediction still has
many taken branch entries, most of which will not be correct.
8455ee3f06