| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir-cpu-runner] Add export_executable_symbols in CMake This patch is primarily about the change in "mlir/tools/mlir-cpu-runner/CMakeLists.txt". LLJIT needs access to symbols (e.g. llvm_orc_registerEHFrameSectionWrapper) that will be defined in the executable when LLVM is linked statically. This change is consistent with how other tools within LLVM use LLJIT. It is required to make sure that: $ mlir-cpu-runner --host-supports-jit correctly returns true on platforms that do support JITting (in my case that's AArch64 Linux). The change in "mlir/lib/ExecutionEngine/CMakeLists.txt" is required to avoid ODR violations when symbols from mlir-cpu-runner are exported and when loading libmlir_async_runtime.so in mlir-cpu-runner. Specifically, to avoid EnableABIBreakingChecks being defined twice. For more context: * https://github.com/llvm/llvm-project/issues/61712 * https://github.com/llvm/llvm-project/issues/61856 * https://reviews.llvm.org/D146935 (this PR) This change relands ccdcfad0815296d8952438632d9abe6bc0a5258a Fixes #61856 Differential Revision: https://reviews.llvm.org/D146935 | 3 年前 | |
[mlir] Move tblgen code generation to use functional forms of cast/isa Summary: The method forms are deprecated. This updates the rest of the tblgen uses of methods where a function call is available. Context: - https://mlir.llvm.org/deprecation/ at "Use the free function variants for dyn_cast/cast/isa/…" - Original discussion at https://discourse.llvm.org/t/preferred-casting-style-going-forward/68443 Reviewers: rriddle | 3 年前 | |
[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][ANALYSIS] Add liveness analysis utility This commit adds a utility to implement liveness analysis using the sparse backward data-flow analysis framework. Theoretically, liveness analysis assigns liveness to each (value, program point) pair in the program and it is thus a dense analysis. However, since values are immutable in MLIR, a sparse analysis, which will assign liveness to each value in the program, suffices here. Liveness analysis has many applications. It can be used to avoid the computation of extraneous operations that have no effect on the memory or the final output of a program. It can also be used to optimize register allocation. Both of these applications help achieve one very important goal: reducing runtime. A value is considered "live" iff it: (1) has memory effects OR (2) is returned by a public function OR (3) is used to compute a value of type (1) or (2). It is also to be noted that a value could be of multiple types (1/2/3) at the same time. A value "has memory effects" iff it: (1.a) is an operand of an op with memory effects OR (1.b) is a non-forwarded branch operand and a block where its op could take the control has an op with memory effects. A value A is said to be "used to compute" value B iff B cannot be computed in the absence of A. Thus, in this implementation, we say that value A is used to compute value B iff: (3.a) B is a result of an op with operand A OR (3.b) A is used to compute some value C and C is used to compute B. --- It is important to note that there already exists an MLIR liveness utility here: llvm-project/mlir/include/mlir/Analysis/Liveness.h. So, what is the need for this new liveness analysis utility being added by this commit? That need is explained as follows:- The similarities between these two utilities is that both use the fixpoint iteration method to converge to the final result of liveness. And, both have the same theoretical understanding of liveness as well. However, the main difference between (a) the existing utility and (b) the added utility is the "scope of the analysis". (a) is restricted to analysing each block independently while (b) analyses blocks together, i.e., it looks at how the control flows from one block to the other, how a caller calls a callee, etc. The restriction in the former implies that some potentially non-live values could be marked live and thus the full potential of liveness analysis will not be realised. This can be understood using the example below: 1 func.func private @private_dead_return_value_removal_0() -> (i32, i32) { 2 %0 = arith.constant 0 : i32 3 %1 = arith.addi %0, %0 : i32 4 return %0, %1 : i32, i32 5 } 6 func.func @public_dead_return_value_removal_0() -> (i32) { 7 %0:2 = func.call @private_dead_return_value_removal_0() : () -> (i32, i32) 8 return %0#0 : i32 9 } Here, if we just restrict our analysis to a per-block basis like (a), we will say that the %1 on line 3 is live because it is computed and then returned outside its block by the function. But, if we perform a backward data-flow analysis like (b) does, we will say that %0#1 of line 7 is not live because it isn't returned by the public function and thus, %1 of line 3 is also not live. So, while (a) will be unable to suggest any IR optimizations, (b) can enable this IR to convert to:- 1 func.func private @private_dead_return_value_removal_0() -> i32 { 2 %0 = arith.constant 0 : i32 3 return %0 : i32 4 } 5 func.func @public_dead_return_value_removal_0() -> i32 { 6 %0 = call @private_dead_return_value_removal_0() : () -> i32 7 return %0 : i32 8 } One operation was removed and one unnecessary return value of the function was removed and the function signature was modified. This is an optimization that (b) can enable but (a) cannot. Such optimizations can help remove a lot of extraneous computations that are currently being done. Signed-off-by: Srishti Srivastava <srishtisrivastava.ai@gmail.com> Reviewed By: matthiaskramm, jcai19 Differential Revision: https://reviews.llvm.org/D153779 | 2 年前 | |
[mlir] Split parser fuzzer for bytecode & text Enable fuzzing these independently. Currently still not linking in dialects beyond Builtin. | 3 年前 | |
[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 年前 | |
[cmake] Fix tablegen exports This fixes some fallout from D131282. Currently, add_tablegen() will add the tablegen target to LLVM_EXPORTS and associates the install with LLVMExports. For non-standalone builds, this means that you end up with mlir-tblgen and clang-tblgen in LLVMExports. However, these projects should instead be using MLIR_EXPORTS/MLIRTargets and CLANG_EXPORTS/ClangTargets. To fix this, add an extra EXPORT option and make use of get_target_export_arg() to create the correct export argument. Reviewed By: ashay-github Differential Revision: https://reviews.llvm.org/D131565 | 3 年前 | |
[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] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9. | 6 年前 | |
[mlir][GPU] Rename MLIRGPUOps CMake target to MLIRGPUDialect This is for consistency with other dialects. Differential Revision: https://reviews.llvm.org/D150659 | 3 年前 | |
Fix ODS verifier emission for DerivedAttr when Properties are enabled Differential Revision: https://reviews.llvm.org/D158679 | 2 年前 | |
[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] Removes CMake work-arounds. CMake older than 3.20.0 is no longer supported. This removes work-arounds for no longer supported versions. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D152101 | 3 年前 | |
[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] Fix checks for native arch Using if (TARGET ${LLVM_NATIVE_ARCH}) only works if MLIR is built together with LLVM, but not for standalone builds of MLIR. The correct way to check this is if (${LLVM_NATIVE_ARCH} IN_LIST LLVM_TARGETS_TO_BUILD), as the LLVM build system exports LLVM_TARGETS_TO_BUILD. To avoid repeating the same check many times, add a MLIR_ENABLE_EXECUTION_ENGINE variable. Differential Revision: https://reviews.llvm.org/D131071 | 3 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 6 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 |