JJohn Ericson[cmake] Don't export LLVM_TOOLS_INSTALL_DIR anymore
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[cmake] Don't export LLVM_TOOLS_INSTALL_DIR anymore First of all, LLVM_TOOLS_INSTALL_DIR put there breaks our NixOS builds, because LLVM_TOOLS_INSTALL_DIR defined the same as CMAKE_INSTALL_BINDIR becomes an *absolute* path, and then when downstream projects try to install there too this breaks because our builds always install to fresh directories for isolation's sake. Second of all, note that LLVM_TOOLS_INSTALL_DIR stands out against the other specially crafted LLVM_CONFIG_* variables substituted in llvm/cmake/modules/LLVMConfig.cmake.in. @beanz added it in d0e1c2a550ef348aae036d0fe78cab6f038c420c to fix a dangling reference in AddLLVM, but I am suspicious of how this variable doesn't follow the pattern. Those other ones are carefully made to be build-time vs install-time variables depending on which LLVMConfig.cmake is being generated, are carefully made relative as appropriate, etc. etc. For my NixOS use-case they are also fine because they are never used as downstream install variables, only for reading not writing. To avoid the problems I face, and restore symmetry, I deleted the exported and arranged to have many ${project}_TOOLS_INSTALL_DIRs. AddLLVM now instead expects each project to define its own, and they do so based on CMAKE_INSTALL_BINDIR. LLVMConfig still exports LLVM_TOOLS_BINARY_DIR which is the location for the tools defined in the usual way, matching the other remaining exported variables. For the AddLLVM changes, I tried to copy the existing pattern of internal vs non-internal or for LLVM vs for downstream function/macro names, but it would good to confirm I did that correctly. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D117977 | 3 年前 | |
[mlir][Linalg] Deprecate tileAndFuseLinalgOps method and associated patterns. The tileAndFuseLinalgOps is a legacy approach for tiling + fusion of Linalg operations. Since it was also intended to work on operations with buffer operands, this method had fairly complex logic to make sure tile and fuse was correct even with side-effecting linalg ops. While complex, it still wasnt robust enough. This patch deprecates this method and thereby deprecating the tiling + fusion method for ops with buffer semantics. Note that the core transformation to do fusion of a producer with a tiled consumer still exists. The deprecation here only removes methods that auto-magically tried to tile and fuse correctly in presence of side-effects. The tileAndFuseLinalgOps also works with operations with tensor semantics. There are at least two other ways the same functionality exists. 1) The tileConsumerAndFuseProducers method. This does a similar transformation, but using a slightly different logic to automatically figure out the legal tile + fuse code. Note that this is also to be deprecated soon. 2) The prefered way uses the TilingInterface for tile + fuse, and relies on the caller to set the tiling options correctly to ensure that the generated code is correct. As proof that (2) is equivalent to the functionality provided by tileAndFuseLinalgOps, relevant tests have been moved to use the interface, where the test driver sets the tile sizes appropriately to generate the expected code. Differential Revision: https://reviews.llvm.org/D129901 | 3 年前 |