[all-commits] [llvm/llvm-project] f8c431: [AMDGPU][NewInsertWaitcnt] Add Event Tracker

[Pierre van Houtryve via All-commits]

  Branch: refs/heads/users/pierre-vh/amdgpu-eventtracker
  Home:   https://github.com/llvm/llvm-project
  Commit: f8c431c6a6db376431c2f2cea3072be15840baa6
      https://github.com/llvm/llvm-project/commit/f8c431c6a6db376431c2f2cea3072be15840baa6
  Author: pvanhout <pierre.vanhoutryve at amd.com>
  Date:   2026-09-28 (Mon, 28 Sep 2026)

  Changed paths:
    A llvm/lib/Target/AMDGPU/AMDGPUEventTracking.cpp
    A llvm/lib/Target/AMDGPU/AMDGPUEventTracking.h
    M llvm/lib/Target/AMDGPU/AMDGPUHWEvents.h
    M llvm/lib/Target/AMDGPU/CMakeLists.txt
    A llvm/unittests/Target/AMDGPU/AMDGPUEventTrackingTest.cpp
    M llvm/unittests/Target/AMDGPU/CMakeLists.txt

  Log Message:
  -----------
  [AMDGPU][NewInsertWaitcnt] Add Event Tracker

See #226335

Introduction

Adds the basic infrastructure needed to track in-flight records for each `InstCounterType`.
This is not a full replacement of `SIInsertWaitcnts::WaitcntBrackets` and it does not
aim to be one.

One goal with the new implementation is to avoid having a single "tracker" class
that does everything. Instead, the `EventTracker` aims to do one thing and do it right:
preserve the history of a counter (instructions + events issued) and the value of the counter.
Any specific queries, such as "what STORE_CNT do I need to use this RU" is something that belongs
to helper methods in the client of the class or a utils file.

Class Design

This class is designed to use a single "source of truth" for all information, which is a compact
timeline of events. The intent is that we'll just iterate the timeline to answer certain queries
instead of baking-in a bunch of `DenseMaps` for every query dimension we need.
This considerably simplifies the implementation. Most of the code in the files here are
boilerplate, assertions, debug dumps, verification methods, and so on. There is very little "critical" logic.

The design/API presented here is *not* final - it'll evolve as we aim for feature parity with
`SIInsertWaitcnts` in the `NewInsertWaitcnts` pass.

Performance

As this design leans on iterating the timeline possibly multiple times per instruction, I made sure it'd be fast
by keeping the record type small (16B right now, may grow to 32) and stored contiguously.
I also did some profiling on very big test cases by shadowing `WaitcntBrackets` and doing many (dozens) of timeline
iteration each instruction for every counter, and there is no visible spike in the flame graph of the profiler.

Testing

I tested this implementation by shadowing the `WaitcntBrackets` class in a downstream branch and checking
my results against it, until I was confident that the values given by the `EventTracker` were as precise or
more precise than the values given by `WaitcntBrackets` for the entire test suite.

Use of AI

AI was exclusively used for 2 things:

- As a design companion, helping me flesh out architecture ideas in "plan mode" so I could iterate fast.
  I also used it as a research tool to find prior art, gather data for me to verify, etc.
- As a refactoring/boilerplate generation tool, such as creating files with basic boilerplate,
  generating scaffolding like methods/class declarations/etc.

AI was not used to write any serious code/algorithms in any function of either the unit tests or the implementation files.

Assisted-by: Claude Opus (4.8/5.5) and Sonnet (5)



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications