This patch changes the syntax of omp.atomic.read to take the address of
destination, instead of having the value in a result. This will allow
using omp.atomic.read operation within an omp.atomic.capture operation
thus making its implementation less complex.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This will allow using omp.atomic.read operation within an omp.atomic.capture operation thus making its implementation less complex.
No clear what this means. It would be good to give the example of how to use omp.atomic.read operation within an omp.atomic.capture operation.
I was planning to add the atomic capture operation like this
// v = x; x = x binop expr; omp.atomic.capture { omp.atomic.read %v = %x : !llvm.ptr<i32> omp.atomic.update %x = %x add %expr : !llvm.ptr<i32>, i32 }
This cannot be done with the current syntax because the read value will be limited by scope. All the forms of atomic capture constructs can be captured like this (with certain restrictions). This will make it less complicated. This is inspired by the format used in OpenMP specification for Fortran here (which will work for C/C++ also):
!$omp atomic capture update-statement capture-statement !$omp end atomic !$omp atomic capture capture-statement update-statement !$omp end atomic !$omp atomic capture capture-statement write-statement !$omp end atomic
where capture-statement is essentially an omp.atomic.read operation.
@shraiysh Can you go ahead and try this method (using atomic.read in atomic.capture structured-block) and verify it in D115851? It may be better to show one whole design instead of part of it.
Another question is that will atomic.write and atomic.update will be used in atomic.capture structured-block and should their syntax also be updated?
Changed argument variable names to be more consistent with other operations and the standard.