[clang] [flang] [flang][RISCV] Add target-abi ModuleFlag. (PR #126188)

2025-02-12 Thread Roger Ferrer Ibáñez via cfe-commits

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)

2025-06-16 Thread Roger Ferrer Ibáñez via cfe-commits

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)

2025-07-14 Thread Roger Ferrer Ibáñez via cfe-commits

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)

2025-07-15 Thread Roger Ferrer Ibáñez via cfe-commits

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)

2025-07-17 Thread Roger Ferrer Ibáñez via cfe-commits


@@ -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