[qt/clang/llvm]: Summary of bulk changes made
KDE Git Services - Bulk Change <[email protected]>
| Newsgroups | gmane.comp.kde.cvs |
|---|---|
| Message-ID | <[email protected]> |
Git repository change summary for qt/clang/llvm Pushed by mirror-service into branch 'upstream/users/pierre-vh/split-waitcntbrackets'. Changed from 0000000000000000000000000000000000000000 to 5201a4fd1e7a30f8845ffafcb72731245e8b780c Acknowledgement was received that this change introduces only existing code that has been pushed to another public open source repository. This change contains the following new commits: Git commit 5201a4fd1e7a30f8845ffafcb72731245e8b780c by pvanhout on 16/07/2026 at 12:10.. [RFC][AMDGPU][InsertWaitcnts] Move `WaitcntBrackets` to a separate file My previous stack of patches de-tangled quite a bit of InsertWaitcnt, and now `WaitcntBrackets` can be moved into a separate file fairly easily. I'm proposing this as a RFC. While I think this is a net positive, I don't want to force this through if others feel it's unnecessary. Implementation: This pretty much moves `WaitcntBrackets` as-is, with a few changes: - Instead of having a pointer to `SIInsertWaitcnts` for the "context" there is now a "Info" class that `SIInsertWaitcnts` implements. This enforces a small separation between the classes, not enough to force a massive redesign, but enough that we can't just access the entire state of `InsertWaitcnts` at will. - Some unused/unnecessary functions were removed or made private. - I reorganized the code a bit: moved all private functions together, moved method implementations to the .cpp if they had more than 2 lines of code. The goal is to keep things somewhat organized so it's easy to glance at the file and see how this works. Motivation: While we have no use for a reusable `WaitcntBrackets` yet, separating it in another file and acting as-if it's meant to be reusable has the big advantage of removing the "god-object" connection between `WaitcntBrackets` and `WaitcntGenerator` via the `SIInsertWaitcnt` class. This helps separate concerns better which, IMHO, will reduce the maintenance burden a bit. This also allows for splitting the decl and definition of `WaitcntBrackets` method, making the API easier to digest at a glance. It gives the implementation a bit more room to grow as well. Future direction: I can imagine splitting `WaitcntGenerator` similarly, but I am not sure yet if that's desirable so we will see. Now that `WaitcntBrackets` is split up, it'd also be nice too move towards a simpler API for it so that the way things are tracked is opaque to `InsertWaitcnt`. Maybe then we can start playing with alternative implementations of `WaitcntBrackets`, like having a more precise, newer tracking system that can be selected dynamically. That's something I'd like to eventually explore as there's been a mention of having a "per-event timeline instead of per-counter timeline" for many years. Assisted-By: Claude Sonnet 5 Claude was only used to generate the boilerplate of the files (create header/cpp + add to CMakeLists). I wrote all the code/logic myself. https://invent.kde.org/qt/clang/llvm/-/commit/5201a4fd1e7a30f8845ffafcb72731245e8b780c