| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Avoid object libraries in the VS IDE (#93519) As discussed in #89743, when using the Visual Studio solution generators, object library projects are displayed as a collection of non-editable *.obj files. To look for the corresponding source files, one has to browse (or search) to the library's obj.libname project. This patch tries to avoid this as much as possible. For Clang, there is already an exception for XCode. We handle MSVC_IDE the same way. For MLIR, this is more complicated. There are explicit references to the obj.libname target that only work when there is an object library. This patch cleans up the reasons for why an object library is needed: 1. The obj.libname is modified in the calling CMakeLists.txt. Note that with use-only references, add_library(<name> ALIAS <target>) could have been used. 2. An libMLIR.so (mlir-shlib) is also created. This works by adding linking the object libraries' object files into the libMLIR.so (in addition to the library's own .so/.a). XCode is handled using the -force_load linker option instead. Windows is not supported. This mechanism is different from LLVM's llvm-shlib that is created by linking static libraries with -Wl,--whole-archive (and -Wl,-all_load on MacOS). 3. The library might be added to an aggregate library. In-tree, the seems to be only libMLIR-C.so and the standalone example. In XCode, it uses the object library and -force_load mechanism as above. Again, this is different from libLLVM-C.so. 4. Build an object library whenever it was before this patch, except when generating a Visual Studio solution. This condition could be removed, but I am trying to avoid build breakages of whatever configurations others use. This seems to never have worked with XCode because of the explicit references to obj.libname (reason 1.). I don't have access to XCode, but I tried to preserve the current working. IMHO there should be a common mechanism to build aggregate libraries for all LLVM projects instead of the 4 that we have now. As far as I can see, this means for LLVM there are the following changes on whether object libraries are created: 1. An object library is created even in XCode if FORCE_OBJECT_LIBRARY is set. I do not know how XCode handles it, but I also know CMake will abort otherwise. 2. An object library is created even for explicitly SHARED libraries for building libMLIR.so. Again, mlir-shlib does not work otherwise. libMLIR.so itself is created using SHARED so this patch is marking it as EXCLUDE_FROM_LIBMLIR. 3. For the second condition, it is now sensitive to whether the mlir-shlib is built at all (LLVM_BUILD_LLVM_DYLIB). However, an object library is still built using the fourth condition unless using the MSVC solution generator. That is, except with MSVC_IDE, when an object library was built before, it will also be an object library now. | 2 年前 | |
[MLIR] Add support for libMLIR.so Putting this up mainly for discussion on how this should be done. I am interested in MLIR from the Julia side and we currently have a strong preference to dynamically linking against the LLVM shared library, and would like to have a MLIR shared library. This patch adds a new cmake function add_mlir_library() which accumulates a list of targets to be compiled into libMLIR.so. Note that not all libraries make sense to be compiled into libMLIR.so. In particular, we want to avoid libraries which primarily exist to support certain tools (such as mlir-opt and mlir-cpu-runner). Note that the resulting libMLIR.so depends on LLVM, but does not contain any LLVM components. As a result, it is necessary to link with libLLVM.so to avoid linkage errors. So, libMLIR.so requires LLVM_BUILD_LLVM_DYLIB=on FYI, Currently it appears that LLVM_LINK_LLVM_DYLIB is broken because mlir-tblgen is linked against libLLVM.so and and independent LLVM components. Previous version of this patch broke depencies on TableGen targets. This appears to be because it compiled all libraries to OBJECT libraries (probably because cmake is generating different target names). Avoiding object libraries results in correct dependencies. (updated by Stephen Neuendorffer) Differential Revision: https://reviews.llvm.org/D73130 | 6 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 2 年前 | ||
| 6 年前 |