[Mlir-commits] [mlir] [mlir][LLVMIR] Add IFuncOp to LLVM dialect (PR #147697)

[Tobias Gysi]

================
@@ -2682,6 +2694,59 @@ unsigned AliasOp::getAddrSpace() {
   return ptrTy.getAddressSpace();
 }
 
+//===----------------------------------------------------------------------===//
+// IFuncOp
+//===----------------------------------------------------------------------===//
+
+void IFuncOp::build(OpBuilder &builder, OperationState &result, StringRef name,
+                    Type iFuncType, StringRef resolverName, Type resolverType,
+                    Linkage linkage, LLVM::Visibility visibility) {
+  return build(builder, result, name, iFuncType, resolverName, resolverType,
+               linkage, /*dso_local=*/false, /*address_space=*/0,
+               UnnamedAddr::None, visibility);
+}
+
+LogicalResult IFuncOp::verifySymbolUses(SymbolTableCollection &symbolTable) {
+  Operation *symbol =
+      symbolTable.lookupSymbolIn(parentLLVMModule(*this), getResolverAttr());
+  auto resolver = dyn_cast<LLVMFuncOp>(symbol);
+  if (!resolver) {
+    // FIXME: Strip aliases to find the called function
+    if (isa<AliasOp>(symbol))
+      return success();
----------------
gysit wrote:

Yeah just lookin for `AddressOfOp` sounds dangerous that could in theory lead to false verification errors on correct code.

I would either just handle the trivial cases where the AliasOp returns a value that is directly defined by an AddressOfOp or we bail out in this case and just return success (which is what you implemented). Did you see real-world examples where there was a lot of code in an AddressOfOp?

Btw can an IFunc refer to another IFunc as well (I would hope not but one never knows)? 


https://github.com/llvm/llvm-project/pull/147697