ergawy wrote: > 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.
If it is ok, let's postpone this issue until later and focus on the multi-range modelling issue first (new op vs. extending current op). Just to make the discussion easier to follow. > -> Is this the do-concurrent to OpenMP conversion pass or an unordered > fir.do_loop conversion to OpenMP pass? Now it is mainly the former. However, we can still do this accurately by attaching an attribute to the op to tell us where the op originated from: an actual `do concurrent` loop or a generated one. I think this way we don't lose accuracy and give ourselves the flexibility of thinking about converting code-gened loops later on a case by case basis. So we would have a "multi-range `fir.op_loop` that can be `unordered` and also carries the information of where it originated from". > -> 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. Since the pass is hidden behind a flag, I left the analysis part for future steps as documented. I understood your point as: which loops are safe to transform/parallelize. I might have not understood what you mean though, please let me know if that's the case. I am not against a separate op, and others who worked on the FIR dialect(s) would have a better informed opinion than me. But I think having a separate `do concurrent` op would unneccisarily complicate the dialect (since we will have 2 separate constructs/ops to model loops and both constructs/ops can reperesent `unordered` execution). Specially that those 2 ops would share lots of similarities. On the other hand, one op flexible enough to give us a detailed understanding of multi-range iteration spaces and where the MLIR originated from on the Fortran source level, I think would be better. Again my opinion, and others may well have better informed opinions than me. 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
