[flang-commits] [flang] [flang][OpenMP] Fix LASTPRIVATE for iteration variables (PR #69773)

[Kiran Chandramohan via flang-commits]

https://github.com/kiranchandramohan approved this pull request.

Thanks @luporl for the fix. Looks fine to me.

Is the update of the original loop variable unconditionally done now? Should it be only if `lastprivate(loop_variable)` is present? Or is the point that the `loop_variable` is always private and hence the value of the original variable is undefined if it is not `lastprivate` and hence it is OK to update always?

> I've just one point to raise (@kiranchandramohan can comment better). Through this approach, we have introduced a mandatory set of 1 arith.addi, 3 arith.cmpi, and 1 arith.select in every iteration of the loop. Again, not very sure about this, but can this have a bearing on performance, since loops are extensively present across benchmarks we use for validation?

Please refer to https://discourse.llvm.org/t/rfc-privatisation-in-openmp-dialect/3526/4. The `kmpc_for_static_init` calls provide a value called `%.omp.is_last` that can be used to check if this is the last iteration. And updates can be placed by checking this value on the last iteration in the exiting path of the loop. One way to achieve this is by having a new operation in the dialect (in-place of the fir.if and related comparisons) say, `omp.last_private_loop_update`, that takes in the loop_variable, step-size as arguments. This can be extracted out and put in the exit path of the loop. Other alternatives include just modelling the lastprivate variables as part of the omp.wsloop construct and appropriately lowering them with the correct conditions and updates only during lowering to LLVM IR. 

Please wait for @NimishMishra.

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