================ @@ -269,6 +269,40 @@ mlir::Operation *CIRGenModule::getGlobalValue(StringRef name) { return mlir::SymbolTable::lookupSymbolIn(theModule, name); } +cir::GlobalOp CIRGenModule::createGlobalOp(CIRGenModule &cgm, + mlir::Location loc, StringRef name, + mlir::Type t, + mlir::Operation *insertPoint) { + cir::GlobalOp g; + CIRGenBuilderTy &builder = cgm.getBuilder(); + + { + mlir::OpBuilder::InsertionGuard guard(builder); + + // Some global emissions are triggered while emitting a function, e.g. + // void s() { const char *s = "yolo"; ... } + // + // Be sure to insert global before the current function + CIRGenFunction *curCGF = cgm.curCGF; + if (curCGF) + builder.setInsertionPoint(curCGF->curFn); + + g = builder.create<cir::GlobalOp>(loc, name, t); + if (!curCGF) { + if (insertPoint) + cgm.getModule().insert(insertPoint, g); ---------------- andykaylor wrote:
I don't see any place else in the incubator where this happens. It seems this is the wrapper where it happens. Beyond this we're into general MLIR code, but a quick search didn't turn up any place there where this pattern occurred. Generally, I don't think it matters where the entries get pushed in the list. The one place we are providing an insert point is when we're replacing a previously declared global. I'm not sure it matters there either honestly. but I guess it makes the output easier to read. https://github.com/llvm/llvm-project/pull/138222 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits