[Backend] Emit bar.warp.sync for barriers of 1 warp

[Mogball]

In warp specialized regions with only 1 warp, we can emit bar.warp.sync instead of barriers with a threadcount. This is slightly more efficient.

[ThomasRaoux]

LGTM

[Mogball]

Clearly something is wrong with this PR. It's not that important to dig into at the moment.

[peterbell10]

E RuntimeError: CUDA error: CUDA-capable device(s) is/are busy or unavailable

I have seen the same issue on other PRs. I think the worker is flaky :/

[ThomasRaoux]

E RuntimeError: CUDA error: CUDA-capable device(s) is/are busy or unavailable

I have seen the same issue on other PRs. I think the worker is flaky :/

GB200 has a lot of instability, sorry about that

[Mogball]

Oh, well I guess this PR got really unlucky? It didn't happen on other PRs I opened.

[Mogball]

Let's try again...

[Jokeren]

I wonder why it's more efficient using bar.warp.sync? Is it just because barriers instructions are slower?

[Jokeren]

Or it's just a measurement noise?

[peterbell10]

bar.warp.sync becomes a no-op when ptxas knows statically that the warp is convergent, which is probably a lot of the time in triton. See in this example, the second bar.warp.sync becomes BSYNC because it comes after a branch but there isn't one emitted before the first branch:
https://gcc.godbolt.org/z/3rMPaenG9