Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Speculative CTRL_FLOW events #14

Open
dr-sc opened this issue Oct 16, 2024 · 1 comment
Open

Speculative CTRL_FLOW events #14

dr-sc opened this issue Oct 16, 2024 · 1 comment

Comments

@dr-sc
Copy link
Contributor

dr-sc commented Oct 16, 2024

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
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants