[llvm] [AMDGPU] Mark `SI_WATERFALL_LOOP` as divergent in `hasDivergentBranch` (PR #218969)

[Igor Wodiany via llvm-commits]

IgWod wrote:

> I thought every lane goes through the same waterfall loop? Do we allow some lanes skip the loop?

Not sure about that. I guess it would make sense if skipping lanes if disallowed; but I still think we can't sink past it.

> I'm guessing lanes that were already inactive when you enter the loop aren't going to take the loop?

That's my understanding. EXEC gets restored to what it was before the loop.

So, I've been looking at the test case. If I remove waterfall loop from the list I get:

```
body:             |
  bb.0:
    successors: %bb.1(0x80000000)
    liveins: $vgpr0, $vgpr1_vgpr2
  
    %0:vgpr_32 = COPY $vgpr0
    %1:vreg_64 = COPY $vgpr1_vgpr2
    %2:sreg_32_xm0_xexec = S_MOV_B32 $exec_lo
  
  bb.1:
    successors: %bb.1(0x40000000), %bb.2(0x40000000)
  
    %3:sreg_32_xm0 = V_READFIRSTLANE_B32 %0, implicit $exec
    %4:sreg_32_xm0_xexec = V_CMP_EQ_U32_e64 %3, %0, implicit $exec
    %5:sreg_32_xm0_xexec = S_AND_SAVEEXEC_B32 killed %4, implicit-def $exec, implicit-def $scc, implicit $exec
    $exec_lo = S_XOR_B32_term $exec_lo, %5, implicit-def $scc
    SI_WATERFALL_LOOP %bb.1, implicit $exec
  
  bb.2:
    $exec_lo = S_MOV_B32 %2
    %6:vgpr_32 = V_ADD_U32_e64 %3, %3, 0, implicit $exec
    FLAT_STORE_DWORD %1, %6, 0, 0, implicit $exec, implicit $flat_scr :: (store (s32))
    SI_RETURN
```

`V_ADD_U32_e64` is sunk, so it'll only write 2 * %3 once using the value from the last iteration and broadcast it to every active lane on loop exit. When `V_ADD` is inside the loop, it'll write different value per lane(s) as %3 is different between iterations (`S_AND_SAVEEXEC_B32` narrows exec -> different active lane(s) -> different value read by `V_READFIRSTLANE_B32`). Does this make sense?

P.S. While writing this I noticed Jay's comment, so I'll pre-commit the test and it should make an impact a bit clearer.

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