[flang-commits] [clang] [flang] [flang][OpenMP] Upstream `do concurrent` loop-nest detection. (PR #127595)

[Kiran Chandramohan via flang-commits]

kiranchandramohan wrote:

> @kiranchandramohan @clementval thanks for your comments (and sorry for the late response, I was off yesterday).
> 
> Sure, we can work on a multi-range loop op in FIR, our team did not write the current loop op definition so I was working with what I have.
> 
> Just to be on the same page, do you suggest to have a separate op for `do concurrent` (separate from the current `fir.do_loop` op)? Or extend the current to model:
> 
> * multi-range iteration
> * and multi-block loop bodies?
> 
> I am leaning towards extending the current op to be more capable/flexible but if you have any reasons not to do so, please let me know.
> 
> In any case, there is not problem blocking this PR until we can model multi-range loops (at least, maybe we can defer multi-block loops to a later point).

Extending the current fir.do_loop operation to model multi-block loop bodies is not recommended, I think. It is there to model structured fortran loops. If you want to handle multi-block loop bodies you will need a new operation.

I am fine with making the most of the current representation if it is possible to do so accurately. But if you have to extend the fir.do_loop operation, you will have to get the nod from the lowering maintainers. (I understand that @jeanPerier  suggested going ahead with your old patch in https://github.com/llvm/llvm-project/pull/77285 but might not have followed the discussion here)

What you have to make clear is:
-> Is this the do-concurrent to OpenMP conversion pass or an unordered fir.do_loop conversion to OpenMP pass? If it is the former, is the current conversion of unordered fir.do_loop only triggered for do-concurrent loops because of where it is called in the pipeline (only encounters hlfir.assign and not unordered fir.do_loop for array assignment and constructors) and there are no other unordered fir.do_loops generated from other Fortran constructs? If it is the latter, is it always safe/correct to do this conversion?
-> What are the do-concurrent features that you can convert accurately (and what you cannot) with the current fir.do_loop, current fir.do_loop with a minor extension, and with adding an hlfir.do-concurrent operation.



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