[flang][OpenMP] Handle non-const bounds in do concurrent host mapping

[ergawy]

Lifts a restriction we had so far for do concurrent -> OpenMP mapping by supporting non-const bounds in loop headers.

[ergawy]

Ping 🔔! Please take a look and let me know if you have any concerns or comments.

[Meinersbur]

I don't see any code handling non-rectangular loop nests of nested DO CONCURRENT. What happens here?

do concurrent(i=1:n)
  do concurrent(j=i:n)
  end do
end do

[ergawy]

Thanks for the review @Meinersbur 🙏!

I don't see any code handling non-rectangular loop nests of nested DO CONCURRENT. What happens here?

I added an item to the Next steps section in the document. Since we don't need that now for the somewhat big application we are valiating (LBL's inference engine), I think it makes sense to leave this as a TODO for (hopefully) near future.

[Meinersbur]

I added an item to the Next steps section in the document. Since we don't need that now for the somewhat big application we are valiating (LBL's inference engine), I think it makes sense to leave this as a TODO for (hopefully) near future.

I assume this means that with this patch applied, it will not try to convert both loops together (although I don't see where it is checking for this case, maybe on the MLIR side?).

Consider adding a test case that checks for non-rectangular loops. Maybe on the MLIR side, but if it becomes too complicated (e.g. involving Flang and MLIR, that would not be a unit test anymore), just leave it as-is.

[ergawy]

I assume this means that with this patch applied, it will not try to convert both loops together (although I don't see where it is checking for this case, maybe on the MLIR side?).

With this patch applied, and the following example:

do concurrent(i=1:n)
  do concurrent(j=i:n)
    ...
  end do
end do

the pass will emit the following warning:

warning: ...: Some `do concurent` loops are not perfectly-nested. These will be serialzied.

The isPerfectlyNested check fails because the live-in set of the inner loop does not contain n. However, this is not a robust test for non-rectagular loops. For that, I would have to detect that at least one of the bounds expressions reference(s) to some of the surrounding loops, right? Something that I can do in a follow-up PR if that is ok with you.