This is an archive of the discontinued LLVM Phabricator instance.

Differential D64375

[OpenMP][Docs] Provide implementation status details
ClosedPublic

Authored by jdoerfert on Jul 8 2019, 3:49 PM.

Details

Reviewers
kkwli0
ABataev
RaviNarayanaswamy
gtbercea
Hahnfeld
Commits
rG40fe351cf699: [OpenMP][Docs] Provide implementation status details
rL370930: [OpenMP][Docs] Provide implementation status details
rC370930: [OpenMP][Docs] Provide implementation status details
Summary

This adds a more fine-grained list of OpenMP features with their
implementation status and associated reviews/commits.

Diff Detail

Event Timeline

jdoerfert created this revision.Jul 8 2019, 3:49 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 8 2019, 3:49 PM
Herald added subscribers: jfb, guansong, bollu. · View Herald Transcript
Harbormaster completed remote builds in B34540: Diff 208530.Jul 8 2019, 3:50 PM
ABataev added a comment.Jul 8 2019, 4:06 PM

The scheme itself looks good in general. Just as an improvement, it would be good to use coloring for the feature status.
Also, what's the difference between claimed, mostly done and done?

clang/docs/OpenMPSupport.rst
153

I'm working on this feature, but don't know when it's going to be ready.

219

Do we really need Fortran stuff here?

237

Not sure 100%, but seems to me it is not done.

jdoerfert marked 2 inline comments as done.Jul 8 2019, 4:21 PM
In D64375#1574662, @ABataev wrote:

The scheme itself looks good in general.

Good. Once we agreed on a scheme we can improve the actual process, excel sheet, generator script, etc. (see also below).

Just as an improvement, it would be good to use coloring for the feature status.

I'll try to add coloring.

Also, what's the difference between claimed, mostly done and done?

Disclaimer: I used a script to determine what the columns in the excel document mean. There is a good chance I got some wrong and it only reflects the information in the document.

I basically used the following logic in this order:

  1. If all non-empty columns contain the word "done", mark it as "done".
  2. If all non-empty columns contain "mostly complete", mark it as "mostly done".
  3. If there are non-empty columns, mark it as "claimed", e.g., someone is working on it.
  4. If there are only empty columns, mark it as "unclaimed", e.g., not being worked on right now.

I think when we go through the excel document now with this use case in mind and fill the empty columns appropriately, some errors will dissapear.

clang/docs/OpenMPSupport.rst
153

That will then be noted in the excel sheet (see general comment).

219

No, I already filtered by hand, my mistake. Will automate it.

ABataev added a comment.Jul 8 2019, 4:27 PM
In D64375#1574698, @jdoerfert wrote:
In D64375#1574662, @ABataev wrote:

The scheme itself looks good in general.

Good. Once we agreed on a scheme we can improve the actual process, excel sheet, generator script, etc. (see also below).

Just as an improvement, it would be good to use coloring for the feature status.

I'll try to add coloring.

Also, what's the difference between claimed, mostly done and done?

Disclaimer: I used a script to determine what the columns in the excel document mean. There is a good chance I got some wrong and it only reflects the information in the document.

I basically used the following logic in this order:

  1. If all non-empty columns contain the word "done", mark it as "done".
  2. If all non-empty columns contain "mostly complete", mark it as "mostly done".
  3. If there are non-empty columns, mark it as "claimed", e.g., someone is working on it.
  4. If there are only empty columns, mark it as "unclaimed", e.g., not being worked on right now.

I think when we go through the excel document now with this use case in mind and fill the empty columns appropriately, some errors will dissapear.

Ok, I see. I will provide more correct feature status tomorrow, if you want. Currently it is not quite correct/full.

lebedev.ri added a subscriber: lebedev.ri.Jul 9 2019, 12:05 AM

Nice, thank you for working on this!

It would be also good to have a not OpenMP-5 specific, but an overview table - which OpenMP thingy was supported starting
with which Clang version, very much like https://clang.llvm.org/cxx_status.html / https://libcxx.llvm.org/cxx1z_status.html,
i needed that a few times.

Hahnfeld added a subscriber: protze.joachim.Jul 9 2019, 3:19 AM
Hahnfeld added inline comments.
clang/docs/OpenMPSupport.rst
165

This is not correct, at least it's not yet upstream.

173

This is wrong as well, at least not upstream (we have multiple versions in local repositories).

ABataev added inline comments.Jul 9 2019, 7:10 AM
clang/docs/OpenMPSupport.rst
161

Done

163

Done

175–177

I don't remember anything related to these items. Seems to me, they are unclaimed

201

Seems to me it is unclaimed

205

Can't find this in the standard.

207

Done.

213

Done

215

Done

233

Done

243

This is just the runtime part, the compiler does not support this

245–247

Not sure that there are special requirements for this in the standard

249

lambdas are supported.

kkwli0 added inline comments.Jul 9 2019, 1:16 PM
clang/docs/OpenMPSupport.rst
205

Section 2.12.7

233

Do we support the behavior in 318:7-14?

237

I think we still need the codegen patch and I am not sure about the runtime part.

243

Since it is a hint according to the specification, I guess it is up to us whether we want to declare this feature done or not. If we do that, we should mention it in the limitation section.

ABataev added inline comments.Jul 9 2019, 1:27 PM
clang/docs/OpenMPSupport.rst
205

Then it is unclaimed, I think.

233

Yes.

237

I don't think it works with unified memory since we don't fully support unified memory.

243

Still, compiler does not use this. WE can mark this as partial, but definitely not done.

jdoerfert added a comment.Jul 9 2019, 2:48 PM

I will update the table (hopefully tomorrow) and we can then see if we commit it and change it in-place or if we have more initial feedback.

Thanks everyone for providing all this information!

@lebedev.ri I'd like to see if we can transition this one into a more generic one with version numbers etc. Is that OK?

lebedev.ri added a comment.Jul 9 2019, 2:49 PM
In D64375#1577153, @jdoerfert wrote:

@lebedev.ri I'd like to see if we can transition this one into a more generic one with version numbers etc. Is that OK?

I have no further comment at the moment.

jdoerfert updated this revision to Diff 209073.Jul 10 2019, 3:00 PM
jdoerfert marked 29 inline comments as done.

Add colors, updates according to comments

Harbormaster completed remote builds in B34718: Diff 209073.Jul 10 2019, 3:03 PM
jdoerfert added inline comments.Jul 10 2019, 3:04 PM
clang/docs/OpenMPSupport.rst
163

Here and above, if there are more revisions, please feel free to add them.

165

Is there anything upstreamed? What should I put for status and revisions/reviews?

205

The excel sheet did assign some of the claimed tasks to people/companies so I will keep them claimed for now and we should ask if they are actually being worked on or not.

207

I only found a 2017 patch which I added but is this completely done? The category suggest this is device related but I did not find device related code.

kkwli0 added inline comments.Jul 10 2019, 3:39 PM
clang/docs/OpenMPSupport.rst
185

parallell -> parallel

189

parallell -> parallel

ABataev added inline comments.Jul 10 2019, 3:42 PM
clang/docs/OpenMPSupport.rst
207

Ah, I missed that this is device extension. Then it is unclaimed.

kkwli0 added inline comments.Jul 10 2019, 3:55 PM
clang/docs/OpenMPSupport.rst
199

Change OMP_TARGET_FALLBACK to OMP_TARGET_OFFLOAD which is in the spec.

jdoerfert updated this revision to Diff 209089.Jul 10 2019, 3:59 PM
jdoerfert marked 4 inline comments as done.

Fixes according to comments

Harbormaster completed remote builds in B34722: Diff 209089.Jul 10 2019, 3:59 PM
Hahnfeld added inline comments.Jul 10 2019, 11:42 PM
clang/docs/OpenMPSupport.rst
165

I don't think there's a review yet. @protze.joachim ?

199

This is done, see the linked revision.

251

I think this should say partial, it's present in libomp after D55078.

jdoerfert added a comment.Jul 25 2019, 7:50 AM

I'll add @Hahnfeld comments, anything else? If not, can someone approve this and we do separate reviews for improvements?

ABataev added a comment.Jul 25 2019, 7:52 AM
In D64375#1601163, @jdoerfert wrote:

I'll add @Hahnfeld comments, anything else? If not, can someone approve this and we do separate reviews for improvements?

Update revision and I'll approve it.

jdoerfert updated this revision to Diff 212957.Aug 1 2019, 7:54 PM

Improve based on two comments by @Hahnfeld

Harbormaster completed remote builds in B36002: Diff 212957.Aug 1 2019, 7:54 PM
Hahnfeld added inline comments.Aug 1 2019, 11:54 PM
clang/docs/OpenMPSupport.rst
223–227

Do we have CodeGen for this? I only remember Sema support...

Also, reverse_offload is listed again below as unclaimed.

233

ping @jdoerfert

251

ping, I still think partial is more correct

jdenny added a subscriber: jdenny.Aug 6 2019, 2:56 PM
ABataev added inline comments.Aug 8 2019, 10:36 AM
clang/docs/OpenMPSupport.rst
223–227

We don't have codegen for this. Same for the reverse_offload and atomic_default_mem_order

ikitayama added a subscriber: ikitayama.Aug 8 2019, 3:28 PM
RaviNarayanaswamy added inline comments.Aug 14 2019, 2:40 PM
clang/docs/OpenMPSupport.rst
223–227

As Alexey said codegen is not done so maybe change it to partial.
Regardng reverse_offload, it is debate able whether keep it unclaimed or make it partial. Yes Sema is done but the hard part for which nobody has claimed is codegen and libomptarget. At least for the getting this initial document checked in we should keep it as unclaimed. Do you have a strong objection against this.

jdoerfert updated this revision to Diff 217631.Aug 28 2019, 6:50 AM
jdoerfert marked 2 inline comments as done.

Update according to comments

Harbormaster completed remote builds in B37433: Diff 217631.Aug 28 2019, 6:54 AM
ABataev added inline comments.Aug 28 2019, 6:58 AM
clang/docs/OpenMPSupport.rst
205

This feature is implemented already

jdoerfert marked an inline comment as done.Sep 4 2019, 8:56 AM
jdoerfert added inline comments.
clang/docs/OpenMPSupport.rst
205

If we wait longer, we can always update this patch. Maybe we should upstream it and update it online.

@RaviNarayanaswamy @kkwli0 @ABataev

ABataev accepted this revision.Sep 4 2019, 8:59 AM

LG

clang/docs/OpenMPSupport.rst
205

Add the latest info and commit it.

This revision is now accepted and ready to land.Sep 4 2019, 8:59 AM
kkwli0 added inline comments.Sep 4 2019, 9:03 AM
clang/docs/OpenMPSupport.rst
205

Agreed.

protze.joachim added inline comments.Sep 4 2019, 9:07 AM
clang/docs/OpenMPSupport.rst
165

There is no review yet. Implementation is available in
https://github.com/OpenMPToolsInterface/LLVM-openmp/tree/ompd-tests

Closed by commit rL370930: [OpenMP][Docs] Provide implementation status details (authored by jdoerfert). · Explain WhySep 4 2019, 10:14 AM
This revision was automatically updated to reflect the committed changes.
jdoerfert marked an inline comment as done.
Herald added a project: Restricted Project. · View Herald TranscriptSep 4 2019, 10:14 AM
Herald added a subscriber: llvm-commits. · View Herald Transcript

Revision Contents

PathSize
clang/
docs/
136 lines

Diff 208530

clang/docs/OpenMPSupport.rst

Show All 11 Lines
.. contents:: .. contents::
:local: :local:
================== ==================
OpenMP Support OpenMP Support
================== ==================
Clang supports the following OpenMP 5.0 features Clang supports the following OpenMP 5.0 features (see also `OpenMP implementation details`_):
* The `reduction`-based clauses in the `task` and `target`-based directives. * The `reduction`-based clauses in the `task` and `target`-based directives.
* Support relational-op != (not-equal) as one of the canonical forms of random * Support relational-op != (not-equal) as one of the canonical forms of random
access iterator. access iterator.
* Support for mapping of the lambdas in target regions. * Support for mapping of the lambdas in target regions.
Show All 10 Lines
* #pragma omp declare simd: :partial:`Partial`. We support parsing/semantic * #pragma omp declare simd: :partial:`Partial`. We support parsing/semantic
analysis + generation of special attributes for X86 target, but still analysis + generation of special attributes for X86 target, but still
missing the LLVM pass for vectorization. missing the LLVM pass for vectorization.
In addition, the LLVM OpenMP runtime `libomp` supports the OpenMP Tools In addition, the LLVM OpenMP runtime `libomp` supports the OpenMP Tools
Interface (OMPT) on x86, x86_64, AArch64, and PPC64 on Linux, Windows, and macOS. Interface (OMPT) on x86, x86_64, AArch64, and PPC64 on Linux, Windows, and macOS.
General improvements General improvements
-------------------- --------------------
- New collapse clause scheme to avoid expensive remainder operations. - New collapse clause scheme to avoid expensive remainder operations.
Compute loop index variables after collapsing a loop nest via the Compute loop index variables after collapsing a loop nest via the
collapse clause by replacing the expensive remainder operation with collapse clause by replacing the expensive remainder operation with
multiplications and additions. multiplications and additions.
- The default schedules for the `distribute` and `for` constructs in a - The default schedules for the `distribute` and `for` constructs in a
▲ Show 20 Lines • Show All 69 Lines • ▼ Show 20 Lines
- Automatic translation of math functions in target regions to device-specific - Automatic translation of math functions in target regions to device-specific
math functions is not implemented yet. math functions is not implemented yet.
- Debug information for OpenMP target regions is supported, but sometimes it may - Debug information for OpenMP target regions is supported, but sometimes it may
be required to manually specify the address class of the inspected variables. be required to manually specify the address class of the inspected variables.
In some cases the local variables are actually allocated in the global memory, In some cases the local variables are actually allocated in the global memory,
but the debug info may be not aware of it. but the debug info may be not aware of it.
.. _OpenMP implementation details:
OpenMP 5.0 Implementation Details
---------------------------------
The following table provides a quick overview over various OpenMP 5.0 features
and their implementation status. Please contact *openmp-dev* at
*lists.llvm.org* for more information or if you want to help with the
implementation.
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
|Category | Feature | Status | Reviews |
+==============================+==============================================================+==============+============================================+
| loop extension | support != in the canonical loop form | done | D54441 |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| loop extension | #pragma omp loop (directive) | unclaimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| loop extension | collapse imperfectly nested loop | unclaimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| loop extension | collapse non-rectangular nested loop | unclaimed | |
ABataevUnsubmitted
Done
ReplyInline Actions

I'm working on this feature, but don't know when it's going to be ready.

ABataev: I'm working on this feature, but don't know when it's going to be ready.
jdoerfertAuthorUnsubmitted
Done
ReplyInline Actions

That will then be noted in the excel sheet (see general comment).

jdoerfert: That will then be noted in the excel sheet (see general comment).
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| loop extension | C++ range-base for loop | unclaimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| loop extension | clause: nosimd for SIMD directives | unclaimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| loop extension | inclusive scan extension (matching C++17 PSTL) | unclaimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| memory mangagement | memory allocators | claimed | |
ABataevUnsubmitted
Done
ReplyInline Actions

Done

ABataev: Done
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| memory mangagement | allocate directive and allocate clause | claimed | r355614,r335952 |
ABataevUnsubmitted
Done
ReplyInline Actions

Done

ABataev: Done
jdoerfertAuthorUnsubmitted
Done
ReplyInline Actions

Here and above, if there are more revisions, please feel free to add them.

jdoerfert: Here and above, if there are more revisions, please feel free to add them.
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| OMPD | OMPD interfaces | mostly done | |
HahnfeldUnsubmitted
Done
ReplyInline Actions

This is not correct, at least it's not yet upstream.

Hahnfeld: This is not correct, at least it's not yet upstream.
jdoerfertAuthorUnsubmitted
Done
ReplyInline Actions

Is there anything upstreamed? What should I put for status and revisions/reviews?

jdoerfert: Is there anything upstreamed? What should I put for status and revisions/reviews?
HahnfeldUnsubmitted
Not Done
ReplyInline Actions

I don't think there's a review yet. @protze.joachim ?

Hahnfeld: I don't think there's a review yet. @protze.joachim ?
protze.joachimUnsubmitted
Not Done
ReplyInline Actions

There is no review yet. Implementation is available in
https://github.com/OpenMPToolsInterface/LLVM-openmp/tree/ompd-tests

protze.joachim: There is no review yet. Implementation is available in https://github.
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| OMPT | OMPT interfaces | mostly done | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| thread affinity extension | thread affinity extension | done | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| task extension | taskloop reduction | done | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| task extension | task affinity | done | |
HahnfeldUnsubmitted
Done
ReplyInline Actions

This is wrong as well, at least not upstream (we have multiple versions in local repositories).

Hahnfeld: This is wrong as well, at least not upstream (we have multiple versions in local repositories).
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| task extension | clause: depend on the taskwait construct | claimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| task extension | depend objects and detachable tasks | claimed | |
ABataevUnsubmitted
Done
ReplyInline Actions

I don't remember anything related to these items. Seems to me, they are unclaimed

ABataev: I don't remember anything related to these items. Seems to me, they are unclaimed
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| task extension | mutexinoutset dependence-type for tasks | done | D53380,D57576 |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| task extension | combined taskloop constructs | unclaimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| task extension | master taskloop | unclaimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| task extension | parallell master taskloop | unclaimed | |
kkwli0Unsubmitted
Done
ReplyInline Actions

parallell -> parallel

kkwli0: parallell -> parallel
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| task extension | master taskloop simd | unclaimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| task extension | parallell master taskloop simd | unclaimed | |
kkwli0Unsubmitted
Done
ReplyInline Actions

parallell -> parallel

kkwli0: parallell -> parallel
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| SIMD extension | atomic and critical constructs inside SIMD code | unclaimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| SIMD extension | SIMD nontemporal | unclaimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | infer target functions from initializers | claimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | infer target variables from initializers | claimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | OMP_TARGET_FALLBACK env variable | claimed | D50522 |
kkwli0Unsubmitted
Done
ReplyInline Actions

Change OMP_TARGET_FALLBACK to OMP_TARGET_OFFLOAD which is in the spec.

kkwli0: Change OMP_TARGET_FALLBACK to OMP_TARGET_OFFLOAD which is in the spec.
HahnfeldUnsubmitted
Not Done
ReplyInline Actions

This is done, see the linked revision.

Hahnfeld: This is done, see the linked revision.
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | support full 'defaultmap' functionality | claimed | |
ABataevUnsubmitted
Done
ReplyInline Actions

Seems to me it is unclaimed

ABataev: Seems to me it is unclaimed
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | device specific functions | unclaimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | clause: device_type | claimed | |
ABataevUnsubmitted
Done
ReplyInline Actions

Can't find this in the standard.

ABataev: Can't find this in the standard.
kkwli0Unsubmitted
Done
ReplyInline Actions

Section 2.12.7

kkwli0: Section 2.12.7
ABataevUnsubmitted
Done
ReplyInline Actions

Then it is unclaimed, I think.

ABataev: Then it is unclaimed, I think.
jdoerfertAuthorUnsubmitted
Done
ReplyInline Actions

The excel sheet did assign some of the claimed tasks to people/companies so I will keep them claimed for now and we should ask if they are actually being worked on or not.

jdoerfert: The excel sheet did assign some of the claimed tasks to people/companies so I will keep them…
ABataevUnsubmitted
Done
ReplyInline Actions

This feature is implemented already

ABataev: This feature is implemented already
jdoerfertAuthorUnsubmitted
Done
ReplyInline Actions

If we wait longer, we can always update this patch. Maybe we should upstream it and update it online.

@RaviNarayanaswamy @kkwli0 @ABataev

jdoerfert: If we wait longer, we can always update this patch. Maybe we should upstream it and update it…
ABataevUnsubmitted
Not Done
ReplyInline Actions

Add the latest info and commit it.

ABataev: Add the latest info and commit it.
kkwli0Unsubmitted
Not Done
ReplyInline Actions

Agreed.

kkwli0: Agreed.
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | clause: in_reduction | claimed | |
ABataevUnsubmitted
Done
ReplyInline Actions

Done.

ABataev: Done.
jdoerfertAuthorUnsubmitted
Done
ReplyInline Actions

I only found a 2017 patch which I added but is this completely done? The category suggest this is device related but I did not find device related code.

jdoerfert: I only found a 2017 patch which I added but is this completely done? The category suggest this…
ABataevUnsubmitted
Done
ReplyInline Actions

Ah, I missed that this is device extension. Then it is unclaimed.

ABataev: Ah, I missed that this is device extension. Then it is unclaimed.
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | omp_get_device_num() | claimed | D54342 |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | structure mapping of references | unclaimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | nested target declare | claimed | D51378 |
ABataevUnsubmitted
Done
ReplyInline Actions

Done

ABataev: Done
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | implicitly map 'this' (this[:1]) | claimed | D55982 |
ABataevUnsubmitted
Done
ReplyInline Actions

Done

ABataev: Done
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | allow access to the reference count (omp_target_is_present) | claimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | Fortran pointer mapping | unclaimed | |
ABataevUnsubmitted
Done
ReplyInline Actions

Do we really need Fortran stuff here?

ABataev: Do we really need Fortran stuff here?
jdoerfertAuthorUnsubmitted
Done
ReplyInline Actions

No, I already filtered by hand, my mistake. Will automate it.

jdoerfert: No, I already filtered by hand, my mistake. Will automate it.
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | requires directive (unified shared memory) | claimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | clause: unified_address, unified_shared_memory | claimed | D52625,D52359 |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | clause: reverse_offload | done | D52780 |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | clause: atomic_default_mem_order | done | D53513 |
HahnfeldUnsubmitted
Not Done
ReplyInline Actions

Do we have CodeGen for this? I only remember Sema support...

Also, reverse_offload is listed again below as unclaimed.

Hahnfeld: Do we have CodeGen for this? I only remember Sema support... Also, `reverse_offload` is listed…
ABataevUnsubmitted
Not Done
ReplyInline Actions

We don't have codegen for this. Same for the reverse_offload and atomic_default_mem_order

ABataev: We don't have codegen for this. Same for the reverse_offload and atomic_default_mem_order
RaviNarayanaswamyUnsubmitted
Not Done
ReplyInline Actions

As Alexey said codegen is not done so maybe change it to partial.
Regardng reverse_offload, it is debate able whether keep it unclaimed or make it partial. Yes Sema is done but the hard part for which nobody has claimed is codegen and libomptarget. At least for the getting this initial document checked in we should keep it as unclaimed. Do you have a strong objection against this.

RaviNarayanaswamy: As Alexey said codegen is not done so maybe change it to partial. Regardng reverse_offload, it…
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | clause: dynamic_allocators | done | D53079 |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | user-defined mappers | claimed | D56326,D58638,D58523,D58074,D60972,D59474 |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | mapping lambda expression | claimed | D51107 |
ABataevUnsubmitted
Done
ReplyInline Actions

Done

ABataev: Done
kkwli0Unsubmitted
Done
ReplyInline Actions

Do we support the behavior in 318:7-14?

kkwli0: Do we support the behavior in 318:7-14?
ABataevUnsubmitted
Done
ReplyInline Actions

Yes.

ABataev: Yes.
HahnfeldUnsubmitted
Not Done
ReplyInline Actions

ping @jdoerfert

Hahnfeld: ping @jdoerfert
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | clause: use_device_addr for target data | claimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | map(replicate) or map(local) when requires unified_shared_me | done | D55719,D55892 |
ABataevUnsubmitted
Done
ReplyInline Actions

Not sure 100%, but seems to me it is not done.

ABataev: Not sure 100%, but seems to me it is not done.
kkwli0Unsubmitted
Done
ReplyInline Actions

I think we still need the codegen patch and I am not sure about the runtime part.

kkwli0: I think we still need the codegen patch and I am not sure about the runtime part.
ABataevUnsubmitted
Done
ReplyInline Actions

I don't think it works with unified memory since we don't fully support unified memory.

ABataev: I don't think it works with unified memory since we don't fully support unified memory.
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | reverse offload | unclaimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| device extension | teams construct on the host device | claimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| atomic extension | hints for the atomic construct | done | D51233 |
ABataevUnsubmitted
Done
ReplyInline Actions

This is just the runtime part, the compiler does not support this

ABataev: This is just the runtime part, the compiler does not support this
kkwli0Unsubmitted
Done
ReplyInline Actions

Since it is a hint according to the specification, I guess it is up to us whether we want to declare this feature done or not. If we do that, we should mention it in the limitation section.

kkwli0: Since it is a hint according to the specification, I guess it is up to us whether we want to…
ABataevUnsubmitted
Done
ReplyInline Actions

Still, compiler does not use this. WE can mark this as partial, but definitely not done.

ABataev: Still, compiler does not use this. WE can mark this as partial, but definitely not done.
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| base language | C11 support | unclaimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| base language | C++11/14/17 support | unclaimed | |
ABataevUnsubmitted
Done
ReplyInline Actions

Not sure that there are special requirements for this in the standard

ABataev: Not sure that there are special requirements for this in the standard
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| base language | lambda support | claimed | |
ABataevUnsubmitted
Done
ReplyInline Actions

lambdas are supported.

ABataev: lambdas are supported.
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| misc extension | array shaping | unclaimed | |
HahnfeldUnsubmitted
Not Done
ReplyInline Actions

I think this should say partial, it's present in libomp after D55078.

Hahnfeld: I think this should say partial, it's present in `libomp` after D55078.
HahnfeldUnsubmitted
Not Done
ReplyInline Actions

ping, I still think partial is more correct

Hahnfeld: ping, I still think `partial` is more correct
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| misc extension | library shutdown (omp_pause_resource[_all]) | claimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| misc extension | metadirectives | unclaimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| misc extension | conditional modifier for lastprivate clause | unclaimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| misc extension | user-defined function variants | unclaimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| misc extensions | pointer/reference to pointer based array reductions | unclaimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+
| misc extensions | prevent new type definitions in clauses | unclaimed | |
+------------------------------+--------------------------------------------------------------+--------------+--------------------------------------------+