Review Board 2.0.15


alpha: make hwrei a control inst

Review Request #740 - Created June 8, 2011 and submitted

Information
Korey Sewell
gem5
default
Reviewers
Default
ali, gblack, nate, stever
alpha: make hwrei a control inst
this always changes the PC and is basically an impromptu branch instruction. why
not speculate on this instead of always be forced to mispredict/squash after the
hwrei gets resolved?

The InOrder model needs this marked as "isControl" so it knows to update the PC
after the ALU executes it. If this isnt marked as control, then it's going to
force the model to check the PC of every instruction at commit (what O3 does?),
and that would be a wasteful check for a very high percentage of instructions.

   
Posted (June 9, 2011, 8:11 a.m.)
You can make it a control instruction -- that shouldn't cause any issues, but making it non-serializing is nearly hopeless. HWREI changes the processor state and effects translation among other things. All PAL code instructions that exist before it in the pipe must be complete before other instructions.  This is especially true since we use ev5 pal code. 

I'm pretty sure that o3 does inst->mispredicted() on every instruction. I'm not sure if this is any faster than first calling isControl() on it, but i doubt it.
  1. OK thanks, does anyone else have any objections to hwrei as a control instruction?
    
    By speculate on hwrei, I meant less of the serialization aspect and more of the speculation behind that instruction. We could possibly get the hwrei correct in the BTB so it's not a 100% mispredict rate there.
    
    You are right in that it's probably negligible performance difference from checking isControl() v. inst->mispredicted(), but I got the inorder model to cache the instruction schedules now so we can basically remove that check all together. It's the difference between not calling inst->isControl() and calling it that I'm referring to as wasteful.