This is an archive of the discontinued LLVM Phabricator instance.

TableGen: honor LLVM_LINK_LLVM_DYLIB by default
Needs ReviewPublic

Authored by nhaehnle on Nov 18 2022, 2:41 AM.

Details

Summary

Most TableGen tools have link dependency chains of the form

${project}-tblgen -> ${project}Support -> LLVMSupport

In LLVM_LINK_LLVM_DYLIB=ON builds, ${project}Support naturally links
aginst LLVMSupport implicitly by linking against libLLVM-*.so, and so
${project}-tblgen ends up with a dependency on the shared library.

Configuring the tool itself with DISABLE_LLVM_LINK_LLVM_DYLIB then
typically leads to LLVMSupport to be also included statically, leading
to duplicate definitions of symbols from LLVMSupport after the dynamic
linker has done its thing.

TableGen tools simply aren't that special: they can be linked dynamically
just fine, and so we do that to simplify the build setup.

The only exception to this rule is llvm-tblgen itself, which must be
statically linked to avoid circular dependencies of the form

llvm-tblgen -> llvm-shlib -> tablegen-generated files -> llvm-tblgen

See: https://discourse.llvm.org/t/rfc-cleaning-up-how-we-link-tablegen-tools/66678

Fixes: https://github.com/llvm/llvm-project/issues/58015

Diff Detail

Event Timeline

nhaehnle created this revision.Nov 18 2022, 2:41 AM
nhaehnle requested review of this revision.Nov 18 2022, 2:41 AM
Herald added projects: Restricted Project, Restricted Project, Restricted Project. · View Herald TranscriptNov 18 2022, 2:41 AM
nhaehnle edited the summary of this revision. (Show Details)Nov 18 2022, 3:07 AM

I think the MLIR parts of this code were written before attempting to create libMLIR.so. Probably these tablegen binaries would have to also avoid linking against libMLIR.so and be statically linked to both llvmSupport and MLIRsupport to work properly. I think the proposed solution is reasonable.

This patch overcomes the issue of cl options being defined multiple times. That is great!

I just tried it on Windows on top of e7fb6c394f519d6e6812f1fbbff1571d5e51f5c4 with (msys2), as well as LLVM_LINK_LLVM_DYLIB, LLVM_BUILD_LLVM_DYLIB, and MLIR enabled. I get the following error:

cmd.exe /C "cd . && C:\msys64\clang64\bin\clang++.exe -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -ffunction-sections -fdata-sections -Werror=mismatched-tags -O3 -DNDEBUG -Wl,--stack,16777216    -Wl,--gc-sections tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/AttrOrTypeDefGen.cpp.obj tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/AttrOrTypeFormatGen.cpp.obj tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/DialectGen.cpp.obj tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/DirectiveCommonGen.cpp.obj tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/EnumsGen.cpp.obj tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/FormatGen.cpp.obj tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/LLVMIRConversionGen.cpp.obj tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/LLVMIRIntrinsicGen.cpp.obj tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/mlir-tblgen.cpp.obj tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/OpClass.cpp.obj tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/OpDefinitionsGen.cpp.obj tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/OpDocGen.cpp.obj tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/OpFormatGen.cpp.obj tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/OpGenHelpers.cpp.obj tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/OpInterfacesGen.cpp.obj tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/OpPythonBindingGen.cpp.obj tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/PassCAPIGen.cpp.obj tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/PassDocGen.cpp.obj tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/PassGen.cpp.obj tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/RewriterGen.cpp.obj tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/SPIRVUtilsGen.cpp.obj -o bin\mlir-tblgen.exe -Wl,--out-implib,lib\libmlir-tblgen.dll.a -Wl,--major-image-version,0,--minor-image-version,0  lib/libMLIRSupportIndentedOstream.a  lib/libMLIRTblgenLib.a  lib/libMLIRTableGen.a  lib/libLLVM-16git.dll.a  -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."
ld.lld: error: undefined symbol: llvm::RecordKeeper::getAllDerivedDefinitionsIfDefined(llvm::StringRef) const
>>> referenced by tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/AttrOrTypeDefGen.cpp.obj:(std::__1::__function::__func<$_2, std::__1::allocator<$_2>, bool (llvm::RecordKeeper const&, llvm::raw_ostream&)>::operator()(llvm::RecordKeeper const&, llvm::raw_ostream&))
>>> referenced by tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/AttrOrTypeDefGen.cpp.obj:(std::__1::__function::__func<$_3, std::__1::allocator<$_3>, bool (llvm::RecordKeeper const&, llvm::raw_ostream&)>::operator()(llvm::RecordKeeper const&, llvm::raw_ostream&))
>>> referenced by tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/AttrOrTypeDefGen.cpp.obj:(std::__1::__function::__func<$_4, std::__1::allocator<$_4>, bool (llvm::RecordKeeper const&, llvm::raw_ostream&)>::operator()(llvm::RecordKeeper const&, llvm::raw_ostream&))
>>> referenced 8 more times

I just checked and I get the same error on a linux system. @nhaehnle, did you try an mlir build with the previously mentioned cmake options?

mgorny added a subscriber: mgorny.Nov 21 2022, 12:36 PM

@nhaehnle, I wanted to check in briefly if you are getting the same error messages?

I haven't looked at this in a while, sorry. I do plan to cycle back to it eventually, but right now my work scheduling is more stack-based than FIFO and this is fairly low down...

That is perfectly fine. I just wanted to let you know that we are still interested in this.