riscv / riscv-performance-events

RISC-V Performance Events Specification
https://jira.riscv.org/browse/RVG-152
Creative Commons Attribution 4.0 International
4 stars 2 forks source link

Speculative CTRL_FLOW events #14

Open dr-sc opened 3 weeks ago

dr-sc commented 3 weeks ago

There were talks about adding speculative CTRL_FLOW events and I would like to clarify if/when such say speculative mis-predictions will be useful. For this it would be great to understand what exactly is going on when a CPU detect mis-predict on a speculative path. I see following variants:

  1. Do partial flush of the pipeline to cancel only those instructions affected by the last mis-predicted branch. Do the designs really implement such partial pipeline clears? If yes – then such speculative events should be useful
  2. Stop fetching and wait for all earlier predictions to be resolved. In this case having speculative mis-predictions event is probably not that useful. If earlier predictions were correct this mis-prediction will be accounted as ret one. If some earlier prediction were incorrect this one becomes mostly irrelevant?
  3. ???

Would be good to hear from someone more knowledgeable in this area.

bcstrongx commented 3 weeks ago

Mispredicted branches are typically partial pipeline flushes, on OOO implementations anyway. Only the instructions following (younger than) the mispredicted branch are flushed, such that the write pointers for the ROB and other structures are rolled back to the entry following the mispredicted branch. Then the frontend is redirected and the uops/insts from the correct target path fill those structures.

A speculative mispredict count would differ from a non-spec count when a younger branch mispredicts before an older branch does. This happens most often when the older branch is dependent on a load that misses the L1, allowing younger branches to execute and resolve before it.

I'm not sure how useful a speculative mispredict count is if a non-spec version is available, but my assumption is that some implementations may not implement non-spec versions of events that can't easily be counted when the inst retires (e.g., INST.RET). This avoids the implementation cost of passing event information down the pipeline to retire.