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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
