Modeling `do concurrent` loops in the `fir` dialect

[bob.belcher]

@jeanPerier

I think there is a use case to allow multiblock body (or maybe use scf.execute_region when that occurs instead of going into degraded mode like currently when there is an “internal” goto inside the do concurrent body).

I think using scf.execute_region makes perfect sense. Thanks for the suggestion! I will keep multiblock bodies in mind from the start.

@jeanPerier

The loop iteration variable are local to the loop, …

@tblah

One small detail is that you don’t need the stores to loop iteration variables (from the surrounding scope) inside of the do_concurrent loop.

I am leaning towards keeping the stores and allocating the iteration variables outside the loop. This will be closer to how OpenMP, for example, expects worksharing loops (and maybe OpenACC as well) where we “privatize” the iteration variable with a delayed privatizer. Once we have locality specifiers for do concurrent, we can model these variables using init just like we use private in the OpenMP case. My main points are:

1. To more easily bridge the gap between do concurrent and the target parallelization models we care about: OpenMP and OpenACC.
2. In the case of sequentializing do concurrent loops, make code-gen easier to handle.
   Let me know if you disagree.

@jeanPerier

…, and would not prevent attaching extra “non-body” region if that would help model data specifier (just noting that to open the design space).

Thanks, I will take a look. For locality specifiers, I hacked what we have in OpenMP to be reused for do concurrent loops. See this PoC. This is just for experimentation, I will write an RFC for shared “Data Management” dialect later (after implementing the proper fir.do_concurrent op )

@jeanPerier

I think we should keep it for array expressions. …

Makes sense, thanks for pointing that out!