[llvm] [Offload] add 'olIterateSymbols' runtime function (PR #213036)
Joseph Huber via llvm-commits
llvm-commits at lists.llvm.org
Thu Jul 30 16:57:18 PDT 2026
================
@@ -1314,19 +1313,61 @@ Error olGetSymbol_impl(ol_program_handle_t Program, const char *Name,
Device, *Program->Image, GlobalObj))
return Res;
- Global = std::make_unique<ol_symbol_impl_t>(GlobalObj.getName().c_str(),
- std::move(GlobalObj));
+ Global = std::make_unique<ol_symbol_impl_t>(std::move(GlobalObj));
}
- *Symbol = Global.get();
- return Error::success();
+ return Global.get();
}
default:
return createOffloadError(ErrorCode::INVALID_ENUMERATION,
"getSymbol kind enum '%i' is invalid", Kind);
}
}
+Error olGetSymbol_impl(ol_program_handle_t Program, const char *Name,
+ ol_symbol_kind_t Kind, ol_symbol_handle_t *Symbol) {
+ std::lock_guard<std::mutex> Lock(Program->SymbolListMutex);
+
+ auto SymbolOrErr = getSymbolImplDetail(Program, Name, Kind);
+ if (!SymbolOrErr)
+ return SymbolOrErr.takeError();
+
+ *Symbol = *SymbolOrErr;
+ return Error::success();
+}
+
+Error olIterateSymbols_impl(ol_program_handle_t Program, ol_symbol_kind_t Kind,
+ ol_symbol_iterate_cb_t Callback, void *UserData) {
+ SymbolKindTy PluginKind;
+ switch (Kind) {
+ case OL_SYMBOL_KIND_KERNEL:
+ PluginKind = SymbolKindTy::Kernel;
+ break;
+ case OL_SYMBOL_KIND_GLOBAL_VARIABLE:
+ PluginKind = SymbolKindTy::GlobalVariable;
+ break;
+ default:
+ return createOffloadError(ErrorCode::INVALID_ENUMERATION,
+ "iterateSymbols kind enum '%i' is invalid", Kind);
+ }
+
+ auto &Device = Program->Image->getDevice();
+ std::lock_guard<std::mutex> Lock(Program->SymbolListMutex);
+
+ Error SymbolErr = Error::success();
+ Error IterateErr = Device.Plugin.getGlobalHandler().iterateSymbols(
+ *Program->Image, PluginKind, [&](StringRef Name) {
+ auto SymbolOrErr = getSymbolImplDetail(Program, Name, Kind);
----------------
jhuber6 wrote:
Symbol lookup is relatively cheap, but I was torn on how to keep the interface 'generic'. The problem is that liboffload defines a symbol as a specific thing, and the plugins could potentially use something that isn't an ELF, hence the tradeoff. For what it's worth, scanning through all the symbols is *never* gonig to be on a hot path. It's always going to be a configuration step.
https://github.com/llvm/llvm-project/pull/213036
More information about the llvm-commits
mailing list