================
@@ -52,10 +62,33 @@ class CIRGenModule : public CIRGenTypeCache {
/// A "module" matches a c/cpp source file: containing a list of functions.
mlir::ModuleOp theModule;
+ clang::DiagnosticsEngine &diags;
+
const clang::TargetInfo ⌖
public:
+ mlir::ModuleOp getModule() const { return theModule; }
+
+ /// Helpers to convert Clang's SourceLocation to an MLIR Location.
----------------
bcardosolopes wrote:
What we get in this case is:
```
module ... {
cir.global external dsolocal @y = #cir.int<22> : !s32i {alignment = 4 : i64}
loc(#loc3)
} loc(#loc)
#loc = loc("a.cpp":0:0)
#loc1 = loc("a.cpp":3:1)
#loc2 = loc("a.cpp":3:9)
#loc3 = loc(fused[#loc1, #loc2])
```
> which location does MLIR expect to work with?
Whatever we tell it should hold. We usually take the presumed (expanded) loc
(from `getSourceRange` or begin/end):
```
mlir::Location CIRGenFunction::getLoc(SourceLocation SLoc) {
// Some AST nodes might contain invalid source locations (e.g.
// CXXDefaultArgExpr), workaround that to still get something out.
if (SLoc.isValid()) {
const SourceManager &SM = getContext().getSourceManager();
PresumedLoc PLoc = SM.getPresumedLoc(SLoc);
StringRef Filename = PLoc.getFilename();
return mlir::FileLineColLoc::get(builder.getStringAttr(Filename),
PLoc.getLine(), PLoc.getColumn());
} else {
// Do our best...
assert(currSrcLoc && "expected to inherit some source location");
return *currSrcLoc;
}
}
```
My take is that this is good enough for CIRGen purposes and can/should probably
be improved when we start working on emitting debug information (where we can
go for non-presumed locs if it makes sense), before that it feels designing
prematurely to me.
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
