| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[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 年前 | |
Finish renaming getOperandSegmentSizeAttr() from operand_segment_sizes to operandSegmentSizes This renaming started with the native ODS support for properties, this is completing it. A mass automated textual rename seems safe for most codebases. Drop also the ods prefix to keep the accessors the same as they were before this change: properties.odsOperandSegmentSizes reverts back to: properties.operandSegementSizes The ODS prefix was creating divergence between all the places and make it harder to be consistent. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D157173 | 2 年前 | |
[backport][mlir] Add Python bindings for DenseResourceElementsAttr. (#66319) Only construction and type casting are implemented. The method to create is explicitly named "unsafe" and the documentation calls out what the caller is responsible for. There really isn't a better way to do this and retain the power-user feature this represents. originally by: Stella Laurenzo reference: https://github.com/llvm/llvm-project/commit/f66cd9e9556a53142a26a5c21a72e21f1579 | 9 个月前 | |
Finish renaming getOperandSegmentSizeAttr() from operand_segment_sizes to operandSegmentSizes This renaming started with the native ODS support for properties, this is completing it. A mass automated textual rename seems safe for most codebases. Drop also the ods prefix to keep the accessors the same as they were before this change: properties.odsOperandSegmentSizes reverts back to: properties.operandSegementSizes The ODS prefix was creating divergence between all the places and make it harder to be consistent. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D157173 | 2 年前 | |
[mlir] Add pass to add comdat to all linkonce functions (#65270) This adds a new pass to add an Any comdat to each linkonce and linkonce_odr function in the LLVM dialect. These comdats are necessary on Windows to allow the default system linker to link binaries containing these functions. (cherry picked from commit a6857156df9a73720fbd9633067d1a61c32dd74e) | 2 年前 | |
[mlir][Toy] Remove unnecessary transpose from chapter 1 example The call to 'multiply_transpose' in the initialization of the variable 'f' was intended to have a shape mismatch. However the variable 'a' has shape <2, 3> and the variable 'c' has shape <3, 2>, so the arguments 'transpose(a)' and 'c' have in fact compatible shapes (<3, 2> both), the opposite of what is wanted here. This commit removes the transpose so that arguments 'a' and 'c' have incompatible shapes <2, 3> and <3, 2>, respectively. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D151897 | 3 年前 | |
[mlir] Fix infinite recursion in alias initializer The alias initializer keeps a list of child indices around. When an alias is then marked as non-deferrable, all children are also marked non-deferrable. This is currently done naively which leads to an infinite recursion if using mutable types or attributes containing a cycle. This patch fixes this by adding an early return if the alias is already marked non-deferrable. Since this function is the only way to mark an alias as non-deferrable, it is guaranteed that if it is marked non-deferrable, all its children are as well, and it is not required to walk all the children. This incidentally makes the non-deferrable marking also O(n) instead of O(n^2) (although not performance sensitive obviously). Differential Revision: https://reviews.llvm.org/D158932 | 2 年前 | |
[mlir][ArmSME] Add tile load op and extend tile store tile size support This extends the existing 'arm_sme.tile_store' op to support all tile sizes and adds a new op 'arm_sme.tile_load', as well as lowerings from vector -> custom ops and custom ops -> intrinsics. Currently there's no lowering for i128. Depends on D154867 Reviewed By: awarzynski, dcaballe Differential Revision: https://reviews.llvm.org/D155306 | 2 年前 | |
[mlir][Interfaces] TilingInterface: Add test case for linalg.copy on memrefs Differential Revision: https://reviews.llvm.org/D153347 | 2 年前 | |
[mlir][Pass] Check supported op types before running a pass Add extra error checking to prevent passes from being run on unsupported ops through the pass manager infrastructure. Differential Revision: https://reviews.llvm.org/D153144 | 2 年前 | |
Finish renaming getOperandSegmentSizeAttr() from operand_segment_sizes to operandSegmentSizes This renaming started with the native ODS support for properties, this is completing it. A mass automated textual rename seems safe for most codebases. Drop also the ods prefix to keep the accessors the same as they were before this change: properties.odsOperandSegmentSizes reverts back to: properties.operandSegementSizes The ODS prefix was creating divergence between all the places and make it harder to be consistent. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D157173 | 2 年前 | |
[Backport][Intrinsics] llvm.memcpy.inline length no longer needs to be constant Reference: https://github.com/llvm/llvm-project/commit/fdf94e1 Originally By: Alex Bradbury <asb@igalia.com> A test change was missing for mlir/test/Target/LLVMIR/llvmir-intrinsics.mlir in the initial commit. | 5 个月前 | |
Finish renaming getOperandSegmentSizeAttr() from operand_segment_sizes to operandSegmentSizes This renaming started with the native ODS support for properties, this is completing it. A mass automated textual rename seems safe for most codebases. Drop also the ods prefix to keep the accessors the same as they were before this change: properties.odsOperandSegmentSizes reverts back to: properties.operandSegementSizes The ODS prefix was creating divergence between all the places and make it harder to be consistent. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D157173 | 2 年前 | |
[NFC][Py Reformat] Reformat python files in mlir subdir This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with black. If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run git checkout --ours <yourfile> and then reformat it with black. If you run into any problems, post to discourse about it and we will try to help. RFC Thread below: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential Revision: https://reviews.llvm.org/D150782 | 3 年前 | |
[mlir] Fix infinite recursion in alias initializer The alias initializer keeps a list of child indices around. When an alias is then marked as non-deferrable, all children are also marked non-deferrable. This is currently done naively which leads to an infinite recursion if using mutable types or attributes containing a cycle. This patch fixes this by adding an early return if the alias is already marked non-deferrable. Since this function is the only way to mark an alias as non-deferrable, it is guaranteed that if it is marked non-deferrable, all its children are as well, and it is not required to walk all the children. This incidentally makes the non-deferrable marking also O(n) instead of O(n^2) (although not performance sensitive obviously). Differential Revision: https://reviews.llvm.org/D158932 | 2 年前 | |
[mlir][math] Modify math.powf to handle negative bases. Powf expansion currently returns NaN when the base is negative. This is because taking natural log of a negative number gives NaN. This patch will square the base and half the exponent, thereby getting around the negative base problem. Reviewed By: rsuderman Differential Revision: https://reviews.llvm.org/D158797 | 2 年前 | |
[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 年前 | |
[mlir-lsp] Add client information to the InitializationParams This is specified in the spec, but we just never really needed it. This allows for users of the LSP libraries to inspect information about the client that is connected to the server. Differential Revision: https://reviews.llvm.org/D155566 | 2 年前 | |
[mlir][ArmSME] Dialect and Intrinsic Op Definition This patch creates the ArmSME dialect, and provides the intrinsic op definition necessary for lowering to LLVM IR. This will cover most instructions interacting with the ZA tile register, not covering SME2 instructions. Source: https://developer.arm.com/documentation/ddi0616/latest Reviewed By: awarzynski, c-rhodes Differential Revision: https://reviews.llvm.org/D152878 | 3 年前 | |
[NFC][Py Reformat] Reformat python files in mlir subdir This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with black. If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run git checkout --ours <yourfile> and then reformat it with black. If you run into any problems, post to discourse about it and we will try to help. RFC Thread below: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential Revision: https://reviews.llvm.org/D150782 | 3 年前 | |
[NFC][Py Reformat] Reformat python files in mlir subdir This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with black. If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run git checkout --ours <yourfile> and then reformat it with black. If you run into any problems, post to discourse about it and we will try to help. RFC Thread below: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential Revision: https://reviews.llvm.org/D150782 | 3 年前 | |
[mlir-reduce] Create proper tmp test files (NFC) This commit ensures that the sh script creates temporary files with mktmp to ensure they do not collide with existing files. The previous behaviour caused sporadic permission issues on a multi-user system. Reviewed By: gysit Differential Revision: https://reviews.llvm.org/D145054 | 3 年前 | |
[mlir] #include CRunnerUtils.h instead of RunnerUtils.h in SPIRV-runner This avoids bazel builds failing after commit bba2b656110209a3d9863b92c060082479b06ab1 because libmlir_test_spirv_cpu_runner_c_wrappers.so registers the same runner functions twice. More precisely, this problem only shows up internally at Google because the bazel build does not have that target. Either way though, it's better to IWYU. | 2 年前 | |
Fix MLIR build failure: error: no member named 'getValue' in 'mlir::OptionalParseResult' Fix #63072 | 2 年前 | |
[mlir] Avoid expensive LLVM IR import warnings The revision adds a flag to the LLVM IR import that avoids emitting expensive warnings about unsupported debug intrinsics and unhandled metadata. Reviewed By: Dinistro Differential Revision: https://reviews.llvm.org/D153625 | 2 年前 | |
[NFC][Py Reformat] Reformat python files in mlir subdir This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with black. If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run git checkout --ours <yourfile> and then reformat it with black. If you run into any problems, post to discourse about it and we will try to help. RFC Thread below: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential Revision: https://reviews.llvm.org/D150782 | 3 年前 | |
[backport][mlir] Add Python bindings for DenseResourceElementsAttr. (#66319) Only construction and type casting are implemented. The method to create is explicitly named "unsafe" and the documentation calls out what the caller is responsible for. There really isn't a better way to do this and retain the power-user feature this represents. originally by: Stella Laurenzo reference: https://github.com/llvm/llvm-project/commit/f66cd9e9556a53142a26a5c21a72e21f1579 | 9 个月前 | |
[NFC][Py Reformat] Reformat python files in mlir subdir This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with black. If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run git checkout --ours <yourfile> and then reformat it with black. If you run into any problems, post to discourse about it and we will try to help. RFC Thread below: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential Revision: https://reviews.llvm.org/D150782 | 3 年前 | |
Adjust "end namespace" comment in MLIR to match new agree'd coding style See D115115 and this mailing list discussion: https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.html Differential Revision: https://reviews.llvm.org/D115309 | 4 年前 | |
[mlir] Update SVE integration tests to use mlir-cpu-runner With the recent addition of "-mattr" and "-march" to the list of options supported by mlir-cpu-runner [1], the SVE integration tests can be updated to use mlir-cpu-runner instead of lli. This will allow better code re-use and more consistency This patch updates 2 tests to demonstrate the new logic. The remaining tests will be updated in the follow-up patches. [1] https://reviews.llvm.org/D146917 Depends on D155403 Differential Revision: https://reviews.llvm.org/D155405 | 2 年前 | |
[mlir] add initial chapters of the transform dialect tutorial The transform dialect has been around for a while and is sufficiently stable at this point. Add the first three chapters of the tutorial describing its usage and extension. Reviewed By: springerm Differential Revision: https://reviews.llvm.org/D151491 | 3 年前 | |
[mlir] Update SVE integration tests to use mlir-cpu-runner With the recent addition of "-mattr" and "-march" to the list of options supported by mlir-cpu-runner [1], the SVE integration tests can be updated to use mlir-cpu-runner instead of lli. This will allow better code re-use and more consistency This patch updates 2 tests to demonstrate the new logic. The remaining tests will be updated in the follow-up patches. [1] https://reviews.llvm.org/D146917 Depends on D155403 Differential Revision: https://reviews.llvm.org/D155405 | 2 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 2 年前 | ||
| 2 年前 | ||
| 9 个月前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 5 个月前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 9 个月前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 2 年前 |