[clang] [OpenACC][CIR] Start work to lower 'loop' (PR #137972)

[Razvan Lupusoru via cfe-commits]

================
@@ -13,17 +13,103 @@
 #include "CIRGenBuilder.h"
 #include "CIRGenFunction.h"
 #include "CIRGenOpenACCClause.h"
-#include "mlir/Dialect/OpenACC/OpenACC.h"
+
 #include "clang/AST/OpenACCClause.h"
 #include "clang/AST/StmtOpenACC.h"
 
+#include "mlir/Dialect/OpenACC/OpenACC.h"
+
 using namespace clang;
 using namespace clang::CIRGen;
 using namespace cir;
 using namespace mlir::acc;
 
 mlir::LogicalResult
 CIRGenFunction::emitOpenACCLoopConstruct(const OpenACCLoopConstruct &s) {
-  cgm.errorNYI(s.getSourceRange(), "OpenACC Loop Construct");
-  return mlir::failure();
+  mlir::Location start = getLoc(s.getSourceRange().getBegin());
+  mlir::Location end = getLoc(s.getSourceRange().getEnd());
+  llvm::SmallVector<mlir::Type> retTy;
+  llvm::SmallVector<mlir::Value> operands;
+  auto op = builder.create<LoopOp>(start, retTy, operands);
+
+  // TODO(OpenACC): In the future we are going to need to come up with a
+  // transformation here that can teach the acc.loop how to figure out the
+  // 'lowerbound', 'upperbound', and 'step'.
+  //
+  // -'upperbound' should fortunately be pretty easy as it should be
+  // in the initialization section of the cir.for loop. In Sema, we limit to
+  // just the forms 'Var = init', `Type Var = init`, or `Var = init` (where it
+  // is an operator= call)`.  However, as those are all necessary to emit for
+  // the init section of the for loop, they should be inside the initial
+  // cir.scope.
+  //
+  // -'upperbound' should be somewhat easy to determine. Sema is limiting this
+  // to: ==, <, >, !=,  <=, >= builtin operators, the overloaded 'comparison'
+  // operations, and member-call expressions.
+  //
+  // For the builtin comparison operators, we can pretty well deduce based on
+  // the comparison what the 'end' object is going to be, and the inclusive
+  // nature of it.
+  //
+  // For the overloaded operators, Sema will ensure that at least one side of
+  // the operator is the init variable, so we can deduce the comparison there
+  // too. The standard places no real bounds on WHAT the comparison operators do
+  // for a `RandomAccessIterator` however, so we'll have to just 'assume' they
+  // do the right thing? Note that this might be incrementing by a different
+  // 'object', not an integral, so it isn't really clear to me what we can do to
+  // determine the other side.
+  //
+  // Member-call expressions are the difficult ones. I don't think there is
+  // anything we can deduce from this to determine the 'end', so we might end up
+  // having to go back to Sema and make this ill-formed.
+  //
+  // HOWEVER: What ACC dialect REALLY cares about is the tripcount, which you
+  // cannot get (in the case of `RandomAccessIterator`) from JUST 'upperbound'
+  // and 'lowerbound'. We will likely have to provide a 'recipe' equivilent to
+  // `std::distance` instead.  In the case of integer/pointers, it is fairly
+  // simple to find: it is just the mathematical subtraction. Howver, in the
+  // case of `RandomAccessIterator`, we have to enable the use of `operator-`.
+  // FORTUNATELY the standard requires this to work correctly for
+  // `RandomAccessIterator`, so we don't have to implement a `std::distance`
+  // that loops through, like we would for a forward/etc iterator.
+  //
+  // 'step': Sema is currently allowing builtin ++,--, +=, -=, *=, /=, and =
+  // operators. Additionally, it allows the equivilent for the operator-call, as
----------------
razvanlupusoru wrote:

equivilent -> equivalent

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