master

文件	最后提交记录	最后更新时间
CMakeLists.txt	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 年前
RISCVVIntrinsicUtils.cpp	[RISCV] Remove unused RequiredFeatures argument from RVVIntrinsic constructor. NFC (#98067) Looks like the usage was removed by 7a5cb15ea6facd82756adafae76d60f36a0b60fd	2 年前