[llvm] [AMDGPU] Balance VM_CNT histories across branches (PR #221115)

Dan Zimmerman via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 9 06:41:47 PDT 2026


danzimm wrote:

> Generally it's better if we can do an optimization that works for every target and is safe

This PR was scoped to mi300/mi350 since that's currently what Meta cares about. What you're saying makes a ton of sense, thank you for clarifying!

> To be frank, the fact that you refer to it such a complex patch as "just" a trick is a red flag to me

Sorry for the miscommunication, by 'trick' I mean specifically that `buffer_inv 0` is a nop which increments `VM_CNT`. Let me try to rephrase without the word trick: without encoding the fact that `buffer_inv 0` can be used to balance `VM_CNT` increments across branches, there's risk that frontends like triton or kernel authors lose out on an optimization opportunity. I'm not in the business of beating horses in any state they may be in, so I'll leave it at that- thank you for your clarifications.

> this is something that needs wider discussion with more people

I initially opened this discussion in the META/AMD shared slack in August, including a link to a PR on the shared private repo containing repro and a writeup- in the write up I describe exactly the contents of this PR. Shucai CC'd Lixun Zhang, otherwise gave positive indication of the direction. It sounds like I didn't have the correct people looped in, which is unfortunate. Are you able to access either of those resources? I recognize it's easy to appear that I'm shooting from the hip: I hope I can show you otherwise.

Since it would appear this communication strategy didn't work what's your preferred forum to discuss AMGPU backend changes? You mention GH issues-- would that be good? And do you have documentation describing what information/research should be seeded in the issue/post/message to be most productive for you? I'm not trying to waste your (or anyone else's) time, so (a) I'll be sure to follow the direction you give me going forward (b) look higher in the stack for optimization opportunities instead of bugging you in the backend to prevent noise/friction like this.

https://github.com/llvm/llvm-project/pull/221115


More information about the llvm-commits mailing list