[clang] [flang] [flang][RISCV] Add target-abi ModuleFlag. (PR #126188)
rofirrim wrote: LGTM. Thanks @topperc ! https://github.com/llvm/llvm-project/pull/126188 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][OpenMP][LoopTransformations] Fix incorrect number of generated loops for Tile and Reverse directives (PR #140532)
rofirrim wrote: > I'm guessing that is a yes, could you @alexey-bataev please approve the > workflows and we proceed to merge? Then we can go straight into the > https://github.com/llvm/llvm-project/pull/139293 PR :) I did that already. https://github.com/llvm/llvm-project/pull/140532 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [llvm] [openmp] [Clang][OpenMP][LoopTransformations] Add support for "#pragma omp fuse" loop transformation directive and "looprange" clause (PR #139293)
rofirrim wrote: Hi all, @eZWALT is changing jobs and kindly asked me if I could finish on his behalf. I plan to go through all the items of feedback and then rebase against main. https://github.com/llvm/llvm-project/pull/139293 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [llvm] [openmp] [Clang][OpenMP][LoopTransformations] Add support for "#pragma omp fuse" loop transformation directive and "looprange" clause (PR #139293)
rofirrim wrote: I'm a bit uncertain with what we want to do with `NumGeneratedLoopNests` and `NumGeneratedLoops`. I understand that, outside of dependent contexts, this is some sort of synthesised attribute (in the base case from analysing the loop nests / canonical loop sequences) that can be used by an enclosing loop transformation to check it is still valid. I wonder if an alternative approach is using a list of integers, one per loop representing the depth of the canonical loop contained in there. In lack of a better name, let's call this the GeneratedLoopSequence (`gls` in the examples, read the examples bottom-up) ```cpp // after unroll gls = [], because it is not partial and there may not be loop anymore #pragma omp unroll // after fuse gls = [ 1 ] #pragma omp fuse // from syntax gls = [ 1, 1 ] { for (...) { } for (...) { } } ``` ```cpp // after fuse gls = [ 6, 1 ] #pragma omp fuse looprange(2, 2) // from syntax gls = [ 6, 1, 1 ] { // after tile gls = [ 6 ] #pragma omp tile sizes(x, y, z) // from syntax gls = [ 3 ] for (...) { for (...) { for (...) { } } } // from syntax gls = [ 1 ] for (...) { } // from syntax gls = [ 1 ] for (...) { } } ``` ```cpp // after split gls = [ 1, 1] #pragma omp split counts(a, b) // from syntax, gls = [ 1 ] for (...) { } ``` (For dependent contexts I was thinking on making the GeneratedLoopSequence an `std::optional`, so it is explicitly absent and can be told apart from `[]`) But I wonder if this approach is enough. I was considering the `apply` clause, when we get to implement it. And maybe a list of integers is not enough? ```cpp // after apply(unroll) gls = [] // after split gls = [ 1, 1 ] #pragma omp split counts(a, b) apply(unroll) // from syntax, gls = [ 1 ] for (...) { } ``` ```cpp // after apply(unroll(2)), non-partial unroll the second loop, gls = [1, ?not a loop anymore? ] // after split gls = [ 1, 1 ] #pragma omp split counts(a, b) apply(unroll(2)) // from syntax, gls = [ 1 ] for (...) { } ``` ```cpp // after apply(split(2) counts(c, d)), gls = [1, [1, 1] ] (?) // after split gls = [ 1, 1 ] #pragma omp split counts(a, b) apply(split(2) counts(c, d)) // from syntax, gls = [ 1 ] for (...) { } ``` ```cpp // after apply(split counts(c, d)), gls = [[1, 1], [1, 1]] (???) // after split gls = [ 1, 1 ] #pragma omp split counts(a, b) apply(split counts(c, d)) // from syntax, gls = [ 1 ] for (...) { } ``` Maybe there is no need to recursively represent all the nested transformation? Other examples, from OpenMP, seem OK: ```cpp void span_apply(double A[128][128]) { // this is not a loop transformation but this is fine because gls is a singleton // and collapse is 2 ≤ 4 #pragma omp for collapse(2) // from apply(grid: reverse, interchange) (this affects the first two loops) gls = [ 4 ] // from tile gls = [ 4 ] #pragma omp tile sizes(16,16) apply(grid: interchange,reverse) // from syntax gls = [ 2 ] for (int i = 0; i < 128; ++i) for (int j = 0; j < 128; ++j) A[i][j] = A[i][j] + 1; } ``` ```cpp void nested_apply(double A[100]) { // after apply(reverse), gls = [ 2 ] // after applyt(intratile: unroll partial(2)), gls = [ 2 ] // after tile: gls = [ 2 ] #pragma omp tile sizes(10) apply(intratile: unroll partial(2) apply(reverse)) // from syntax, gls = [ 1 ] for (int i = 0; i < 100; ++i) A[i] = A[i] + 1; } ``` Thoughts? https://github.com/llvm/llvm-project/pull/139293 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [llvm] [openmp] [Clang][OpenMP][LoopTransformations] Add support for "#pragma omp fuse" loop transformation directive and "looprange" clause (PR #139293)
@@ -1143,6 +1143,83 @@ class OMPFullClause final : public OMPNoChildClause { static OMPFullClause *CreateEmpty(const ASTContext &C); }; +/// This class represents the 'looprange' clause in the +/// '#pragma omp fuse' directive +/// +/// \code {c} +/// #pragma omp fuse looprange(1,2) +/// { +/// for(int i = 0; i < 64; ++i) +/// for(int j = 0; j < 256; j+=2) +/// for(int k = 127; k >= 0; --k) +/// \endcode +class OMPLoopRangeClause final +: public OMPClause { + friend class OMPClauseReader; + /// Location of '(' + SourceLocation LParenLoc; + + /// Location of first and count expressions + SourceLocation FirstLoc, CountLoc; + + /// Number of looprange arguments (always 2: first, count) + static constexpr unsigned NumArgs = 2; + Stmt *Args[NumArgs] = {nullptr, nullptr}; + + /// Set looprange 'first' expression + void setFirst(Expr *E) { Args[0] = E; } + + /// Set looprange 'count' expression + void setCount(Expr *E) { Args[1] = E; } + + /// Build an empty clause for deserialization. + explicit OMPLoopRangeClause() + : OMPClause(llvm::omp::OMPC_looprange, {}, {}) {} + +public: + /// Build a 'looprange' clause AST node. + static OMPLoopRangeClause * + Create(const ASTContext &C, SourceLocation StartLoc, SourceLocation LParenLoc, + SourceLocation FirstLoc, SourceLocation CountLoc, + SourceLocation EndLoc, Expr* First, Expr* Count); rofirrim wrote: `clang-format` from LLVM 20 seems to be OK with this :thinking: https://github.com/llvm/llvm-project/pull/139293 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [llvm] [openmp] [Clang][OpenMP][LoopTransformations] Add support for "#pragma omp fuse" loop transformation directive and "looprange" clause (PR #139293)
rofirrim wrote: > Need a rebase Done. I still owe you to split that new `enum`. @Meinersbur if you have thoughts about this comment here https://github.com/llvm/llvm-project/pull/139293#issuecomment-3074305797 , I'd be very thankful. https://github.com/llvm/llvm-project/pull/139293 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits