SchrodingerZhu wrote: Does https://mlir.llvm.org/docs/Dialects/Builtin/#fusedloc suit the situation? On Thu, Oct 31, 2024 at 15:48, David Olsen ***@***.***> wrote: @dkolsen-pgi commented on this pull request. In clang/lib/CIR/CodeGen/CIRGenModule.cpp: > @@ -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()); +} 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.) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>
https://github.com/llvm/llvm-project/pull/113483 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
