This is an archive of the discontinued LLVM Phabricator instance.

[OpenMP] Implement OpenMP 5.0 Affinity Format Functionality

Authored by jlpeyton on Nov 30 2018, 2:26 PM.



This patch adds the affinity format functionality introduced in OpenMP 5.0.
This patch adds: Two new environment variables:


and Four new API:

  1. omp_set_affinity_format()
  2. omp_get_affinity_format()
  3. omp_display_affinity()
  4. omp_capture_affinity()

The affinity format functionality has two ICV's associated with it:
affinity-display-var (bool) and affinity-format-var (string).
The affinity-display-var enables/disables the functionality through the
envirable OMP_DISPLAY_AFFINITY. The affinity-format-var is a formatted
string with the special field types beginning with a '%' character
similar to printf
For example, the affinity-format-var could be:
"OMP: host:%H pid:%P OStid:%i num_threads:%N thread_num:%n affinity:{%A}"

The affinity-format-var is displayed by every thread implicitly at the beginning
of a parallel region when any thread's affinity has changed (including a brand
new thread being spawned), or explicitly using the omp_display_affinity() API.
The omp_capture_affinity() function can capture the affinity-format-var in a
char buffer. And omp_set|get_affinity_format() allow the user to set|get the
affinity-format-var explicitly at runtime. omp_capture_affinity() and
omp_get_affinity_format() both return the number of characters needed to hold
the entire string it tried to make (not including NULL character). If not enough buffer space is available,
both these functions truncate their output.

Diff Detail


Event Timeline

jlpeyton created this revision.Nov 30 2018, 2:26 PM
This revision is now accepted and ready to land.Dec 10 2018, 9:46 AM
This revision was automatically updated to reflect the committed changes.
kiranchandramohan added inline comments.

@jlpeyton @AndreyChurbanov Is there any particular reason that these functions are not bind(c)?

Herald added a project: Restricted Project. · View Herald Transcript
jlpeyton added inline comments.Oct 30 2023, 11:31 AM

@kiranchandramohan , The reason stems from Fortran and C/C++ having different ways of representing strings. In Fortran, the strings don't have to be '\0' byte terminated and there is an implied string size argument for each string argument in the Fortran API. So for these API additions, there is a separate "truly Fortran" entry point (hence, the lack of bind(c)) and C/C++ entry point which eventually converge to a C/C++ oriented implementation i.e., all methods internally assume null-byte termination since the runtime library itself is written in C/C++.

I think we can almost always use bind(c) and only have one entry point in the library for both C/C++/Fortran, but in this case we needed to separate the Fortran API from the C/C++ API because it was the first OpenMP API that dealt with strings.


Thanks @jlpeyton for the explanation.