dev_17.0.6

TTobias Hieta[mlir] Fix crash when adding nested dialect extensions

cc7e24c7创建于 2023年8月31日历史提交

文件	最后提交记录	最后更新时间
Analysis	[MLIR][Presburger] Implement domain and range restriction for PresburgerRelation This patch implements domain and range restriction for PresburgerRelation Reviewed By: Groverkss Differential Revision: https://reviews.llvm.org/D154798	2 年前
Bytecode	Fix bytecode reader/writer on big-endian platforms This makes the bytecode reader/writer work on big-endian platforms. The only problem was related to encoding of multi-byte integers, where both reader and writer code make implicit assumptions about endianness of the host platform. This fixes the current test failures on s390x, and in addition allows to remove the UNSUPPORTED markers from all other bytecode-related test cases - they now also all pass on s390x. Also adding a GFAIL_SKIP to the MultiModuleWithResource unit test, as this still fails due to an unrelated endian bug regarding decoding of external resources. Differential Revision: https://reviews.llvm.org/D153567 Reviewed By: mehdi_amini, jpienaar, rriddle	3 年前
Conversion	[mlir][arith] Change dialect name from Arithmetic to Arith Suggested by @lattner in https://discourse.llvm.org/t/rfc-define-precise-arith-semantics/65507/22. Tested with: ninja check-mlir check-mlir-integration check-mlir-mlir-spirv-cpu-runner check-mlir-mlir-vulkan-runner check-mlir-examples and bazel build --config=generic_clang @llvm-project//mlir:all. Reviewed By: lattner, Mogball, rriddle, jpienaar, mehdi_amini Differential Revision: https://reviews.llvm.org/D134762	3 年前
Debug	Introduce MLIR Op Properties This new features enabled to dedicate custom storage inline within operations. This storage can be used as an alternative to attributes to store data that is specific to an operation. Attribute can also be stored inside the properties storage if desired, but any kind of data can be present as well. This offers a way to store and mutate data without uniquing in the Context like Attribute. See the OpPropertiesTest.cpp for an example where a struct with a std::vector<> is attached to an operation and mutated in-place: struct TestProperties { int a = -1; float b = -1.; std::vector<int64_t> array = {-33}; }; More complex scheme (including reference-counting) are also possible. The only constraint to enable storing a C++ object as "properties" on an operation is to implement three functions: - convert from the candidate object to an Attribute - convert from the Attribute to the candidate object - hash the object Optional the parsing and printing can also be customized with 2 extra functions. A new options is introduced to ODS to allow dialects to specify: let usePropertiesForAttributes = 1; When set to true, the inherent attributes for all the ops in this dialect will be using properties instead of being stored alongside discardable attributes. The TestDialect showcases this feature. Another change is that we introduce new APIs on the Operation class to access separately the inherent attributes from the discardable ones. We envision deprecating and removing the getAttr(), getAttrsDictionary(), and other similar method which don't make the distinction explicit, leading to an entirely separate namespace for discardable attributes. Recommit d572cd1b067f after fixing python bindings build. Differential Revision: https://reviews.llvm.org/D141742	3 年前
Dialect	[mlir][sparse] admit un-sparsifiable operations if all its operands are loaded from dense input Reviewed By: aartbik Differential Revision: https://reviews.llvm.org/D153998	2 年前
ExecutionEngine	[mlir] Fix unit tests after LLVM commit 8b1771bd9f3.	3 年前
IR	[mlir] Fix crash when adding nested dialect extensions A dialect extension can add additional dialect extensions in its apply function. This used to crash when the vector of extensions was internally reallocated while it is being iterated over. Differential Revision: https://reviews.llvm.org/D158838	2 年前
Interfaces	[mlir] Add support for "promised" interfaces Promised interfaces allow for a dialect to "promise" the implementation of an interface, i.e. declare that it supports an interface, but have the interface defined in an extension in a library separate from the dialect itself. A promised interface is powerful in that it alerts the user when the interface is attempted to be used (e.g. via cast/dyn_cast/etc.) and the implementation has not yet been provided. This makes the system much more robust against misconfiguration, and ensures that we do not lose the benefit we currently have of defining the interface in the dialect library. Differential Revision: https://reviews.llvm.org/D120368	3 年前
Parser	[mlir][Parser] Make parse{Attribute,Type} null-terminate input parseAttribute and parseType require null-terminated strings as input, but this isn't great considering the argument type is StringRef. This changes them to copy to a null-terminated buffer by default, with a isKnownNullTerminated flag added to disable the copying. closes #58964 Reviewed By: rriddle, kuhar, lattner Differential Revision: https://reviews.llvm.org/D145182	3 年前
Pass	Fix MLIR pass manager initialization: hash the pass pipeline to detect when initialization is needed The current logic hashes the context to detect registration changes and re-run the pass initialization. However it wasn't checking for changes to the pipeline, so a pass that would get added after a first run would not be initialized during subsequent runs. Reviewed By: Mogball Differential Revision: https://reviews.llvm.org/D158377	2 年前
Rewrite	Fix memory leaks in MLIR unit-tests (NFC)	4 年前
Support	[mlir][docgen] Handle Windows line endings in doc generation. The printReindented function searches for Unix style line endings (\n), but strings may have Windows style line endings (\r\n). Prior to this change, generated document sections could have extra indentation, which some markdown renderers interpret as code blocks rather than paragraphs. Differential Revision: https://reviews.llvm.org/D153591	2 年前
TableGen	[mlir] Update method cast calls to function calls The MLIR classes Type/Attribute/Operation/Op/Value support cast/dyn_cast/isa/dyn_cast_or_null functionality through llvm's doCast functionality in addition to defining methods with the same name. This change begins the migration of uses of the method to the corresponding function call as has been decided as more consistent. Note that there still exist classes that only define methods directly, such as AffineExpr, and this does not include work currently to support a functional cast/isa call. 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 Implementation: This follows a previous patch that updated calls op.cast<T>()-> cast<T>(op). However some cases could not handle an unprefixed cast call due to occurrences of variables named cast, or occurring inside of class definitions which would resolve to the method. All C++ files that did not work automatically with cast<T>() are updated here to llvm::cast and similar with the intention that they can be easily updated after the methods are removed through a find-replace. See https://github.com/llvm/llvm-project/compare/main...tpopp:llvm-project:tidy-cast-check for the clang-tidy check that is used and then update printed occurrences of the function to include llvm:: before. One can then run the following: ninja -C $BUILD_DIR clang-tidy run-clang-tidy -clang-tidy-binary=$BUILD_DIR/bin/clang-tidy -checks='-*,misc-cast-functions'\ -export-fixes /tmp/cast/casts.yaml mlir/*\ -header-filter=mlir/ -fix rm -rf $BUILD_DIR/tools/mlir/**/*.inc Differential Revision: https://reviews.llvm.org/D150348	3 年前
Transforms	Introduce MLIR Op Properties This new features enabled to dedicate custom storage inline within operations. This storage can be used as an alternative to attributes to store data that is specific to an operation. Attribute can also be stored inside the properties storage if desired, but any kind of data can be present as well. This offers a way to store and mutate data without uniquing in the Context like Attribute. See the OpPropertiesTest.cpp for an example where a struct with a std::vector<> is attached to an operation and mutated in-place: struct TestProperties { int a = -1; float b = -1.; std::vector<int64_t> array = {-33}; }; More complex scheme (including reference-counting) are also possible. The only constraint to enable storing a C++ object as "properties" on an operation is to implement three functions: - convert from the candidate object to an Attribute - convert from the Attribute to the candidate object - hash the object Optional the parsing and printing can also be customized with 2 extra functions. A new options is introduced to ODS to allow dialects to specify: let usePropertiesForAttributes = 1; When set to true, the inherent attributes for all the ops in this dialect will be using properties instead of being stored alongside discardable attributes. The TestDialect showcases this feature. Another change is that we introduce new APIs on the Operation class to access separately the inherent attributes from the discardable ones. We envision deprecating and removing the getAttr(), getAttrsDictionary(), and other similar method which don't make the distinction explicit, leading to an entirely separate namespace for discardable attributes. Recommit d572cd1b067f after fixing python bindings build. Differential Revision: https://reviews.llvm.org/D141742	3 年前
CMakeLists.txt	Fix MLIR bytecode loading of resources The bytecode reader didn't handle properly the case where resource names conflicted and were renamed, leading to orphan handles in the IR as well as overwriting the exiting resources. Differential Revision: https://reviews.llvm.org/D151408	3 年前