[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
