[flang-commits] [flang] [flang][acc] Implement cache directive lowering (PR #174897)

[via flang-commits]

================
@@ -86,6 +87,25 @@ struct OutlineRematerializationModel
     : public mlir::acc::OutlineRematerializationOpInterface::ExternalModel<
           OutlineRematerializationModel<Op>, Op> {};
 
+/// External model to implement FortranVariableOpInterface for acc::CacheOp.
+struct CacheFortranVariableModel
----------------
khaki3 wrote:

The issue is that the current pattern generates redundant `hlfir.declare` operations. Looking at the generated IR:

```mlir
// Outside the loop - the variable is already declared
%4:2 = hlfir.declare %arg0(%3) {uniq_name = "_QFsubEr"} : ... -> (!fir.ref<...>, !fir.ref<...>)

// acc.private receives the already-declared variable %4#0
%5 = acc.private varPtr(%4#0 : !fir.ref<...>) -> !fir.ref<...> {name = "r"}

// Inside the loop - another hlfir.declare wrapping the private result
%8:2 = hlfir.declare %5(%3) {uniq_name = "_QFsubEr"} : ...

// The designate uses the second declare's result
%12 = hlfir.designate %8#0 (%11) : ...
```

The variable `r` is declared once outside (`%4`), then `acc.private` takes that declared result (`%4#0`), and then we declare it **again** (`%8`) just to wrap the private result. This second declare is redundant.

With this change for `acc.cache`:

```mlir
// Outside - variable is declared
%4:2 = hlfir.declare %arg0(%3) {uniq_name = "_QFsubEr"} : ...

// acc.cache receives the already-declared variable
%18 = acc.cache varPtr(%4#0 : !fir.ref<...>) -> !fir.ref<...> {name = "r"}

// The designate uses cache result DIRECTLY - no second declare
%23 = hlfir.designate %18 (%22) : ...
```

The `FortranVariableOpInterface` on `acc.cache` allows it to be used directly as a variable definition, eliminating the redundant intermediate declare. This same optimization could apply to `acc.private` and other data operations.


https://github.com/llvm/llvm-project/pull/174897