================
@@ -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());
+}
----------------
AaronBallman wrote:
> It is wanting ClangIR to play nicely with the rest of the MLIR ecosystem,
> when many dialects are mixed together in a single tree later in the
> compilation chain, that makes using SourceLocation problematic.
However, that's also an internal implementation detail that doesn't need to be
exposed to users of the CIR library. Clang works in `SourceLocation`; if CIR
needs to work in something else, that should be abstracted away from the user.
Still not saying this needs to be solved as part of this patch, but
`CIRGenModule::getLoc()` are public interfaces currently; can those be made
private so we're not leaking an implementation detail of CIR to users?
> But later passes won't have access to a SourceLocation.
Two things:
1) Diagnostics that depend on optimization levels have massive usability
issues, so diagnostics from later passes strikes me as a potential design
concern to start with; hopefully we don't end up in that situation except in
very rare circumstances.
2) The backend does occasionally need to issue user-facing diagnostics (things
like `__attribute__((error))` come to mind) and this has been a huge source of
pain because LLVM does a pretty bad job of tracking source location with
sufficient fidelity for Clang to have good QoI. If MLIR has the same issues,
that should be something the MLIR folks work to correct before we transition to
CIR as a default.
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
