-
Notifications
You must be signed in to change notification settings - Fork 14.7k
[clang][OpenMP] New OpenMP 6.0 threadset clause #135807
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 6 commits
9c56e59
bcc7c38
d700caa
11deb35
57fd6ad
6294629
bd92f54
de0c387
bf4f531
3aefe97
4f899b7
7680b55
507ee09
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -3700,6 +3700,7 @@ CGOpenMPRuntime::emitTaskInit(CodeGenFunction &CGF, SourceLocation Loc, | |
DestructorsFlag = 0x8, | ||
PriorityFlag = 0x20, | ||
DetachableFlag = 0x40, | ||
FreeAgentFlag = 0x100, | ||
Ritanya-B-Bharadwaj marked this conversation as resolved.
Show resolved
Hide resolved
|
||
}; | ||
unsigned Flags = Data.Tied ? TiedFlag : 0; | ||
bool NeedsCleanup = false; | ||
|
@@ -3709,6 +3710,11 @@ CGOpenMPRuntime::emitTaskInit(CodeGenFunction &CGF, SourceLocation Loc, | |
if (NeedsCleanup) | ||
Flags = Flags | DestructorsFlag; | ||
} | ||
if (const auto *Clause = D.getSingleClause<OMPThreadsetClause>()) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Better to pass the flag as part of the Data parameter There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry, but could you clarify why that would be necessary? All the flags above seem to be combined using the | operator, so this appears consistent. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To keep all the flags and processing in one single place There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry, I’m not sure I fully understand. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For this flag, I followed the existing pattern where flags are handled directly, not through the data parameter, to stay consistent. Since the other flags are also managed this way, it didn’t seem necessary to change it just for this case. However, if you think using the data parameter is the right approach, I can take it up separately as a new task — to modify the existing features and add support for passing all flags via the data parameter. |
||
OpenMPThreadsetKind Kind = Clause->getThreadsetKind(); | ||
if (Kind == OMPC_THREADSET_omp_pool) | ||
Flags = Flags | FreeAgentFlag; | ||
} | ||
if (Data.Priority.getInt()) | ||
Flags = Flags | PriorityFlag; | ||
if (D.hasClausesOfKind<OMPDetachClause>()) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without a proper runtime implementation (more than the current stub), I would not consider this feature as done. At the moment the table does not distinguish compiler/runtime support, so the field should reflect the missing runtime part.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noted! Does this seem better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess its a POV question :) From an implementer's perspective you are right: the implementation is compliant. From an user's perspective the implementation is at the lowest level of QoI.
I'm not completely sure about the target audience of the page, but I assumed it's part of the user documentation: https://clang.llvm.org/docs/OpenMPSupport.html#openmp-6-0-implementation-details
As a reference:
nowait clause on taskwait
claims partial. I think the implementation status is the same: compiler works, and the runtime implementation currently defaults to fallback code that at least provides a compliant solution.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed! Modified accordingly.