This is an archive of the discontinued LLVM Phabricator instance.

[mlir][OpenMP] Change the syntax of omp.atomic.read op
ClosedPublic

Authored by shraiysh on Dec 29 2021, 11:17 PM.

Details

Summary

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.

Diff Detail

Event Timeline

shraiysh created this revision.Dec 29 2021, 11:17 PM
shraiysh requested review of this revision.Dec 29 2021, 11:17 PM
shraiysh updated this revision to Diff 396619.Dec 29 2021, 11:26 PM

Added check for not allowing same values of src and dest.

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.

shraiysh added a comment.EditedDec 30 2021, 7:55 AM

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.

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.

Got it. I like this form more. Go ahead and do it.

Thanks @peixin. Can you please review this patch?

peixin added a comment.Jan 1 2022, 7:27 AM

@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?

shraiysh updated this revision to Diff 397482.Jan 5 2022, 1:51 AM

Changed argument variable names to be more consistent with other operations and the standard.

@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?

@peixin I have updated D115851 to implement omp.atomic.capture using this new syntax of omp.atomic.read. It used omp.atomic.write and omp.atomic.update but no change in their syntax is required for that. Both these patches are ready for review now.

peixin added a comment.Jan 5 2022, 5:40 AM

@shraiysh Thanks for the update. I will review this and D115851 later this week.

peixin accepted this revision.Jan 6 2022, 12:40 AM

LGTM

This revision is now accepted and ready to land.Jan 6 2022, 12:40 AM
shraiysh updated this revision to Diff 398544.Jan 10 2022, 2:20 AM

Rebase with main.

This revision was automatically updated to reflect the committed changes.