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

[HW] Faster hazard handling for VLDU and SLDU #203

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

mp-17
Copy link
Collaborator

@mp-17 mp-17 commented Jan 20, 2023

Part of #190

  1. Handle slide1x and widening hazards with a special protocol

    Slide1Up/Down were blocked in the main sequencer when they had specific
    hazards. Now, these hazards are handled downstream, waiting for 1 cycle
    of stall and then continuing with the usual protocol.
    WAW hazards for widening instructions are also handled better now,
    discriminating between real widening instructions and reductions.

  2. Handle WAW and WAR vload hazards in the VLDU

    Before this commit, all the hazards (RAW, WAR, WAW) are handled
    by the operand requesters that throttle access to source reg elements.
    Even if the hazard is a WAR/WAW, the suboptimal but efficient way to
    deal with it is to slow down the source reg fetch.
    If an instruction does not have source regs, this cannot happen. For
    example, load instructions. Therefore, all the instructions that do
    not have vector source operands are stalled in the sequencer.
    Loads are super common, and stalling in the main sequencer means
    that all the instructions after the load are also stalled and cannot
    start their execution.
    Therefore, now they are processed, and the hazard check is done inside
    the VLDU. The write-back request is masked until there is no more any
    hazards on that load instruction.

Changelog

Changed

  • Handle WAW and WAR vload hazards in the VLDU
  • Handle slide1x and widening hazards with a special protocol

Checklist

  • No IPC degradation
  • No frequency degradation
  • Automated tests pass
  • Changelog updated
  • Code style guideline is observed

mp-17 added 3 commits January 20, 2023 15:55
Before this commit, all the hazards (RAW, WAR, WAW) are handled
by the operand requesters that throttle access to source reg elements.
Even if the hazard is a WAR/WAW, the suboptimal but efficient way to
deal with it is to slow down the source reg fetch.
If an instruction does not have source regs, this cannot happen. For
example, load instructions. Therefore, all the instructions that do
not have vector source operands are stalled in the sequencer.
Loads are super common, and stalling in the main sequencer means
that all the instructions after the load are also stalled and cannot
start their execution.
Therefore, now they are processed, and the hazard check is done inside
the VLDU. The write-back request is masked until there is no more any
hazards on that load instruction.
Slide1Up/Down were blocked in the main sequencer when they had specific
hazards. Now, these hazards are handled downstream, waiting for 1 cycle
of stall and then continuing with the usual protocol.
WAW hazards for widening instructions are also handled better now,
discriminating between real widening instructions and reductions.
@mp-17
Copy link
Collaborator Author

mp-17 commented Jan 26, 2023

The effect on IPC is not clear. Some kernels have worse performance. From a quick look, I see that the bank conflicts differ; but it seems to be more than that.

@mp-17 mp-17 marked this pull request as draft January 26, 2023 16:48
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

Successfully merging this pull request may close these issues.

2 participants