i965: fix cycle estimates when there's a pipeline stall

The issue time for an instruction is how many cycles it takes to
actually put it into the pipeline. If there's a pipeline stall that
causes the instruction to be delayed, we should first take that into
account to figure out when the instruction would start executing and
*then* add the issue time. The old code had it backwards, and so we
would underestimate the total time whenever we thought there would be a
pipeline stall by up to the issue time of the instruction.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
This commit is contained in:
Connor Abbott 2015-06-05 19:20:57 -04:00
parent 04c42f3ab5
commit 6f231fddff

View file

@ -1405,18 +1405,19 @@ instruction_scheduler::schedule_instructions(bblock_t *block)
instructions_to_schedule--;
update_register_pressure(chosen->inst);
/* If we expected a delay for scheduling, then bump the clock to reflect
* that. In reality, the hardware will switch to another hyperthread
* and may not return to dispatching our thread for a while even after
* we're unblocked. After this, we have the time when the chosen
* instruction will start executing.
*/
time = MAX2(time, chosen->unblocked_time);
/* Update the clock for how soon an instruction could start after the
* chosen one.
*/
time += issue_time(chosen->inst);
/* If we expected a delay for scheduling, then bump the clock to reflect
* that as well. In reality, the hardware will switch to another
* hyperthread and may not return to dispatching our thread for a while
* even after we're unblocked.
*/
time = MAX2(time, chosen->unblocked_time);
if (debug) {
fprintf(stderr, "clock %4d, scheduled: ", time);
bs->dump_instruction(chosen->inst);