> On 2011-02-11 23:03:34, Gabe Black wrote: > > There are a number of problems with the code, but without getting into > > that, I think this is solving the problem from the wrong angle. > > > > I actually ran into what I think is the same thing with X86 recently, and > > it's correct for O3 to mark this as a mispredict in the middle of the > > macroop. The following microops will see the wrong pc state, although they > > may not care, and the pc will diverge at the end just as much as it will in > > the middle. > > > > The problem is that O3 will clobber the adjusted npc because the > > getExtMachInst function for ARM will do what it did for x86 and always > > adjust npc to point to the end of the instruction it just fetched. That's > > fine if the pc is out of the blue since npc is just a guess at that point, > > but if the pc was corrected for a mispredict (or anything else that causes > > refetching mid macroop) then the new, purposeful npc gets blasted. In x86, > > I have a patch out that handles that by explicitly tracking the size of the > > current instruction in the pc. That gets cleared when the PC advances, and > > if it's not set (ie. a size of 0) then the npc needs to be adjusted since > > the size was previously unknown. If the size was not 0, then this is a pc > > where the size was already taken into account and the npc is whatever it is > > on purpose.
What are you're other issues with this? I'd rather not introduce another mechanism to the ARM PCState. It's complex enough already and it seems like a lot of work to fix this single problematic case (I understand it might be much more general on x86). - Ali ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/474/#review846 ----------------------------------------------------------- On 2011-02-11 16:44:30, Ali Saidi wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/474/ > ----------------------------------------------------------- > > (Updated 2011-02-11 16:44:30) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > ------- > > RFE changes control, so the last uop needs to do this otherwise the o3 thinks > there is a mispredict. > > > Diffs > ----- > > src/arch/arm/insts/macromem.hh 6548721032fa > src/arch/arm/insts/macromem.cc 6548721032fa > src/arch/arm/insts/mem.hh 6548721032fa > src/arch/arm/intregs.hh 6548721032fa > src/arch/arm/isa/insts/ldr.isa 6548721032fa > src/arch/arm/isa/insts/macromem.isa 6548721032fa > src/arch/arm/isa/insts/mem.isa 6548721032fa > src/arch/arm/isa/operands.isa 6548721032fa > src/arch/arm/isa/templates/macromem.isa 6548721032fa > src/arch/arm/isa/templates/mem.isa 6548721032fa > > Diff: http://reviews.m5sim.org/r/474/diff > > > Testing > ------- > > > Thanks, > > Ali > >
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
