[flang][acc] Avoid implicitly privatizing IVs already privatized (#136181)

When generating `acc.loop`, the IV was always implicitly privatized.
However, if the user explicitly privatized it, the IR generated wasn't
quite right.

For example:
```
  !$acc loop private(i)
  do i = 1, n
    a(i) = b(i)
  end do
```

The IR generated looked like:
```
    %65 = acc.private varPtr(%19#0 : !fir.ref<i32>) -> !fir.ref<i32>
{implicit = true, name = "i"}
    %66:2 = hlfir.declare %65 {uniq_name = "_QFEi"} : (!fir.ref<i32>) ->
(!fir.ref<i32>, !fir.ref<i32>)
    %67 = acc.private varPtr(%66#0 : !fir.ref<i32>) -> !fir.ref<i32>
{name = "i"}
    acc.loop  private(@privatization_ref_i32 -> %65 : !fir.ref<i32>,
@privatization_ref_i32 -> %67 : !fir.ref<i32>) control(%arg0 : i32) =
(%c1_i32_46 : i32) to (%c10_i32_47 : i32)  step (%c1_i32_48 : i32) {
      fir.store %arg0 to %66#0 : !fir.ref<i32>
```

In order to fix this, we first process all of the clauses. Then when
attempting to generate implicit private IV, we look for an already
existing data clause operation.

The result is the following IR:
```
    %65 = acc.private varPtr(%19#0 : !fir.ref<i32>) -> !fir.ref<i32>
{name = "i"}
    %66:2 = hlfir.declare %65 {uniq_name = "_QFEi"} : (!fir.ref<i32>) ->
(!fir.ref<i32>, !fir.ref<i32>)
    acc.loop  private(@privatization_ref_i32 -> %65 : !fir.ref<i32>)
control(%arg0 : i32) = (%c1_i32_46 : i32) to (%c10_i32_47 : i32)  step
(%c1_i32_48 : i32) {
      fir.store %arg0 to %66#0 : !fir.ref<i32>
```

0 files changed, 0 insertions, 0 deletions