[llvm] [AMDGPU] Check all incoming edges before deleting soft waits (PR #211684)

Jeffrey Byrnes via llvm-commits llvm-commits at lists.llvm.org
Tue Jul 28 08:21:45 PDT 2026


jrbyrnes wrote:

> > 2. Additionally, since these soft waits may be optimized out, we must not use them to simplify e.g. vm_vsrc unless we know they will be used to resolve the outstanding events (e.g. will not be optimized out).
> 
> > 2. Simplify the soft waits before using them to simplify other waits. For example, if we use the raw wait values of the soft wait in our `CheckWait` for vm_vsrc, we may conclude it covers the vm_vsrc, even if we ultimately optimize out the soft wait. Thus, we first simplify the soft waits, to remove these from the `CheckWait` in the case where they are not promoted.
> 
> Issue #2 doesn't make sense to me. If there is a soft wait for vm_vsrc <= N then we would only optimize it out if vm_vsrc is already known to be <= N. In either case, it is still fine to do other optimizations based on the fact that at that point in the code, vm_vsrc is known to be <= N.

To clarify, exposure to #2 is introduced after changing the algorithm to visit all predecessors. I would want to double check the details, but IIRC the issue is that we may insert vm_vsrc at the soft-wait, then update the brackets to note that we've cleared the events. Then when we revisit these soft waits for the other predecessor, we think the soft wait is sufficient given the new brackets state, and we optimize out the vm_vsrc. The main point I'm trying to convey is that the issue is introduced by the new iteration structure, and is not fixed by https://github.com/llvm/llvm-project/pull/212481

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


More information about the llvm-commits mailing list