This revision adds support for dynamic user conditions in OpenMP metadirectives resolvable at runtime. Parsing identifies when clauses of variants (including the default clause) and matches against the OpenMP context to forward applicable when clauses for code generation. Code generation generates dynamic variants checking runtime user conditions and the best match of the statically resolvable condition variants to fall back.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Does anyone implement/take care of the "otherwise" clause? If I am correct, OpenMP 5.2 supports otherwise instead of the default for meta directive.
clang/lib/CodeGen/CGStmtOpenMP.cpp | ||
---|---|---|
1852 | This approach is valid for static conditions. How you are going to take care of multiple dynamic/runtime conditions? |
clang/lib/CodeGen/CGStmtOpenMP.cpp | ||
---|---|---|
1793 | Why are you skipping the AST building part? Any special significance of this approach? |
clang/lib/CodeGen/CGStmtOpenMP.cpp | ||
---|---|---|
1793 | I don't understand the question, what do you mean by that? Emit generates code to handle dynamic and static conditions based on the when clauses | |
1852 | See GenerateCond that creates code for dynamic conditions. If the when clause has dynamically evaluated conditions it generates basicblocks and control logic. |
clang/lib/CodeGen/CGStmtOpenMP.cpp | ||
---|---|---|
1852 | Why get a score for static when clauses for the best clause? Is it according to OpenMP specification? |
Are you going to work on it? Just confirming. I am working on D122255. The code generation part for the dynamic condition is useful. However, my understanding is that it is not according to the OpenMP 5.2 specification. Correct me if I am wrong.
I'm happy if you'd like to take over in your patch. I'm not sure what is the issue with the OpenMP 5.2 but feel free to re-use/modify parts of this patch. One thing that is problematic with this patch is the need to re-set the tokens in the lexer/parser to their unannotated versions when tentative parsing. The code in the patch is not fault-proof but I have an update for that that I can post, if that's useful. In D122255 I see you're taking the route of parsing the associated statement which has its own pitfalls but maybe that's the best approach.
clang/lib/CodeGen/CGStmtOpenMP.cpp | ||
---|---|---|
1852 | Because if no runtime conditions evaluate to true then it falls back to the static when with the highest score. I'm not sure about the OpenMP specification. Do you have an example? Could you point me to the related part in the specification it fails to conform to? |
Why are you skipping the AST building part? Any special significance of this approach?