This is an archive of the discontinued LLVM Phabricator instance.

[flang] Add atomic_fetch_or to the list of intrinsics
ClosedPublic

Authored by ktras on Sep 1 2022, 5:50 PM.

Details

Summary

Add the atomic subroutine, atomic_fetch_or, to the list of
intrinsic subroutines. Add new enumerators to deal with the rank
of the atom dummy argument, and the kind of atomic_int_kind.

Diff Detail

Event Timeline

ktras created this revision.Sep 1 2022, 5:50 PM
Herald added a project: Restricted Project. · View Herald Transcript
Herald added a subscriber: jdoerfert. · View Herald Transcript
ktras requested review of this revision.Sep 1 2022, 5:50 PM
ktras added a comment.Sep 1 2022, 6:01 PM

In this patch, in flang/lib/Evaluate/intrinsics.cpp, I would like to be able to bring in and use the value atomic_int_kind from the iso_fortran_env module. I have drafted my solution in this patch where I declare a variable with the value of atomic_int_kind but with the bind(c) attribute in a new Fortran module and then use an extern int in a .h file to theoretically grab that value. However, I have not done much Fortran/C interoperability and am not sure how to do the right CMake changes to make my idea work. At the moment, I commented out the extern int and am just using a magic number. Would anyone be able to help me figure out how to make the right CMake changes so I can use that extern int? Or is there a totally different and better way to get a value equivalent to atomic_int_kind that is not a magic number?

Maybe @klausler has an idea to manage computing atomic_int_kind in https://github.com/llvm/llvm-project/blob/main/flang/include/flang/Runtime/magic-numbers.h and use that in both the module file and the compiler (I don't) ?

As an alternative however, instead of the cmake gymnastic, I would suggest moving the definition of atomic_int_kind parameter as __builting_atomic_int_kind in https://github.com/llvm/llvm-project/blob/main/flang/module/__fortran_builtins.f90, rename it as atomic_int_kind in https://github.com/llvm/llvm-project/blob/main/flang/module/iso_fortran_env.f90, and extract the builtin parameter symbol and its value in a similar way as it is done for builtin types in GetBuiltinDerivedType defined here: https://github.com/llvm/llvm-project/blob/2944f8ef049fa83ee96159c390fa893f251558da/flang/lib/Evaluate/intrinsics.cpp#L1202.

flang/lib/Evaluate/intrinsics.cpp
1670

I am not well versed in coarrays, and the standard phrasing "shall be a scalar coarray or coindexed object" is a bit ambiguous to me. Are you sure the "scalar" part does not also apply to coindexed objects ? It is not entirely clear to me why it would apply on Corarray and not coarray references.

@jeanPerier Thank you for the feedback! I think the idea to use flang/module/__fortran_builtins.f90 seems like a great idea and I will pursue that option. Thank you for pointing out how that could be useful in this case.

flang/lib/Evaluate/intrinsics.cpp
1670

@jeanPerier, As you saw, the interpretation I took is that in that sentence in the standard, scalar only modifies coarray and not coindexed-object, but I am not sure that this interpretation is correct. I can see your point that this interpretation doesn't make as much sense. @rouson, can you give feedback on this coarray question? Do you know whether "shall be a scalar coarray or coindexed object" in 16.9.25 in the 2018 standard means that a coindexed-object shall also be scalar? Or just if it is a coarray?

rouson added inline comments.Sep 26 2022, 11:22 AM
flang/lib/Evaluate/intrinsics.cpp
1670

I debated whether "scalar" modifies just "coarray" or also "coindexed object" and concluded that the most reasonable answer is that "scalar" modifies both. Otherwise, the standard would be treating coindexed data entities differently from non-coindexed ones, which would create the odd circumstance that we could do something with coindexed entities even in single-image execution that we could not do with non-coindexed entities.

ktras planned changes to this revision.Sep 26 2022, 11:34 AM

I will updated my patch based on reviewer feedback on the implementation of one of the new errors and the implementation of the atomic_int_kind check.

flang/lib/Evaluate/intrinsics.cpp
1670

That is a good point about the single-image execution. Thank you @jeanPerier and @rouson for this discussion. I will change the way I implement my error check for that sentence in the standard to work based on the interpretation that scalar modifies both coarray and coindexed-object.

ktras updated this revision to Diff 463105.Sep 27 2022, 12:09 AM

Update patch based on reviewer feedback:

  • Update the implementation of checks surrounding atomic_int_kind
  • Update implementation of checks on the rank of the atom argument
  • Update atomic_fetch_or test with new error messages and an additional non-standard conforming call.
ktras marked 2 inline comments as done.Sep 27 2022, 12:10 AM

A nit and a question, otherwise looks good to me.

flang/lib/Evaluate/intrinsics.cpp
1665

nit: argOk = rank == 0 && (IsCoarray(*arg) || ExtractCoarrayRef(*arg)); would be readable and shorter.

flang/module/iso_fortran_env.f90
20

Is there a reason to define new parameters instead of doing renaming here (e.g., `atomic_int_kind
=> __builtin_atomic_int_kind`) ?

If renames are possible, I think they should be favored because they avoid "spilling" the builtin symbols. With the current patch, a user using iso_fortran_env could directly use __builtin_atomic_int_kind and __builtin_atomic_logical_kind, and I do not think we should allow that to make it impossible for users to start relying on the builtin names for any weird reason as if it was an extension.

ktras updated this revision to Diff 463613.Sep 28 2022, 10:40 AM
  • Add a check for a coindexed-object for the optional dummy argument 'stat', which "shall be a noncoindexed integer scalar".
  • Updates based on reviewer feedback
ktras marked 2 inline comments as done.Sep 28 2022, 10:43 AM
ktras added inline comments.
flang/module/iso_fortran_env.f90
20

No, there is no reason to define new parameters, but I didn't even think about taking out the original definition fully. Thanks for the great feedback!

ktras marked an inline comment as done.Sep 28 2022, 10:45 AM
This revision is now accepted and ready to land.Sep 29 2022, 6:27 AM
This revision was automatically updated to reflect the committed changes.