================
@@ -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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
