on #5, is it the case that the branch is always mispredicted on a squashDueToMemOrder() ??? I would think so because you havent got the branch back right?
Sounds like there is a couple issues to tackle: 1) Where to start fetching while you wait for resolution? ---> a: look in the BTB for a predicted address and if so use that PC to fetch from. --------->If it's not in the BTB, you can start fetching down the not-taken path there. ---> b: Stall fetch at that point until the branch resolves. This would be similar to the "trapPending" flags that is used to keep fetch from going down a known wrong path I think. 2) Micro-op or fix up the branch? - I would say change the branch at that point there to always mispredict (maybe set the predictedPC to 0) to prevent using a dated prediction. - If you do the BTB think I suggested above then use that as the predictedPC - Then, once the branch resolves, let the normal mechanisms check against the predictedPC and it should squash always (if you reset the predPC to 0) or squash conditionally if you use the BTB to updated your predictedPC. - With regards to already outstanding squash, as long as that outstanding squash is not the oldest squash then your most recent squash will be used. This may provide a quirky problem with the microops depending on how those get their sequence numbers. However, I'll leave further elaboration on the micro-op option to Gabe/Ali since they are more in tune with any gotchas on that end, but I think you could do this without a microop a little cleaner. On Tue, Apr 26, 2011 at 3:12 PM, Geoffrey Blake <bla...@umich.edu> wrote: > I've run into a buggy interaction for the ARM ISA between a TBH (or TBB) > instruction and a dependent memory operation (that gets squashed) in the O3 > model leading to erroneous behavior when diffed against the Atomic model. > The TBH instruction is a table-based branch that has to index into memory > to > calculate its branch destination, so it is both a branch and a memory op. > The buggy behavior is as follows: > > 1) Fetch a TBH, predict branch destination > 2) Begin fetching from predicted PC (which happens to be correct in my > buggy > run) > 3) Issue younger dependent memory op to LSQ and send request to cache ahead > of TBH which is waiting on register operands > 4) Issue TBH to LSQ to read memory for branch destination > 5) Memory violation detection with younger instruction and squash for > memory > ordering > --- This squash then calls squashDueToMemOrder(...), which redirects the > PC of Fetch to a stale PC value stored in the TBH dyn-inst object as it > hasn't yet calculated its true PC > 6) Start fetching down wrong path > 7) TBH completes, but since the branch part was predicted correctly, no > additional squash happens in checkMisprediction (which it may not even > check > due the already outstanding squash) > > I see two ways to fix this, either hack up the O3 model to handle this case > of a fused memory-op and branch instruction (recheck to squash when the TBH > finally resolves for the special case of squashing dependent memory ops > causing the fetch to screw up the branch), or split the instruction into 2 > micro-ops (the load and then a dependent branch). Which one do people > think > would be the better option? I'm currently leaning toward micro-coding the > instruction. > > Thanks, > Geoff Blake > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > -- - Korey _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
