================
@@ -24,9 +27,140 @@ CIRGenModule::CIRGenModule(mlir::MLIRContext &context,
clang::ASTContext &astctx,
const clang::CodeGenOptions &cgo,
DiagnosticsEngine &diags)
- : astCtx(astctx), langOpts(astctx.getLangOpts()),
- theModule{mlir::ModuleOp::create(mlir::UnknownLoc())},
- target(astCtx.getTargetInfo()) {}
+ : builder(&context), astCtx(astctx), langOpts(astctx.getLangOpts()),
+ theModule{mlir::ModuleOp::create(mlir::UnknownLoc::get(&context))},
+ diags(diags), target(astCtx.getTargetInfo()) {}
+
+mlir::Location CIRGenModule::getLoc(SourceLocation cLoc) {
+ assert(cLoc.isValid() && "expected valid source location");
+ const SourceManager &sm = astCtx.getSourceManager();
+ PresumedLoc pLoc = sm.getPresumedLoc(cLoc);
+ StringRef filename = pLoc.getFilename();
+ return mlir::FileLineColLoc::get(builder.getStringAttr(filename),
+ pLoc.getLine(), pLoc.getColumn());
+}
----------------
dkolsen-pgi wrote:
I am guessing that the MLIR location type doesn't have any notion of multiple
nested locations due to macro expansions. So we can't represent the full
complexity of macros here. The outermost location seems like the right one to
choose. (I am not familiar with either the Clang location type or the MLIR
location type, so I welcome being corrected here.)
https://github.com/llvm/llvm-project/pull/113483
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
