aboutsummaryrefslogtreecommitdiff
path: root/mlir/unittests/Dialect/SPIRV/SerializationTest.cpp
AgeCommit message (Collapse)AuthorFilesLines
8 days[mlir][NFC] update `mlir/Dialect` create APIs (30/n) (#150643)Maksim Levental1-6/+6
See https://github.com/llvm/llvm-project/pull/147168 for more info.
2024-10-14[MLIR] Update APInt construction to correctly set isSigned/implicitTrunc ↵Nikita Popov1-1/+1
(#110466) This fixes all the places in MLIR that hit the new assertion added in #106524, in preparation for enabling it by default. That is, cases where the value passed to the APInt constructor is not an N-bit signed/unsigned integer, where N is the bit width and signedness is determined by the isSigned flag. The fixes either set the correct value for isSigned, or set the implicitTrunc flag to retain the old behavior. I've left TODOs for the latter case in some places, where I think that it may be worthwhile to stop doing implicit truncation in the future. Note that the assertion is currently still disabled by default, so this patch is mostly NFC. This is just the MLIR changes split off from https://github.com/llvm/llvm-project/pull/80309.
2024-02-21Apply clang-tidy fixes for readability-identifier-naming in ↵Mehdi Amini1-3/+3
SerializationTest.cpp (NFC)
2024-02-20Apply clang-tidy fixes for performance-unnecessary-value-param in ↵Mehdi Amini1-1/+1
SerializationTest.cpp (NFC)
2023-06-05[mlir][spirv] Change numeric constant's bit-extension decision to be based ↵Md Abdullah Shahneous Bari1-0/+49
on type Integer constants with bit width less than a word (e.g., i8, i16) should be bit extended based on its type to be SPIR-V spec-compliant. Previously, the decision was based on the most significant bit of the value which ignores the signless semantics and causes problems when interfacing with SPIR-V tools. Dealing with numeric literals: the SPIR-V spec says, "If a numeric type’s bit width is less than 32-bits, the value appears in the low-order bits of the word, and the high-order bits must be 0 for a floating-point type or integer type with Signedness of 0, or sign extended for an integer type with a Signedness of 1 (similarly for the remaining bits of widths larger than 32 bits but not a multiple of 32 bits)." Therefore, signless integers (e.g., i8, i16) and unsigned integers should be 0-extended, and signed integers (e.g., si8, si16) should be sign-extended. Patch By: mshahneo Reviewed By: kuhar Differential Revision: https://reviews.llvm.org/D151767
2022-08-09[mlir][spirv] Migrate to use specalized enum attributesLei Zhang1-5/+5
Previously we are using IntegerAttr to back all SPIR-V enum attributes. Therefore we all such attributes are showed like IntegerAttr in IRs, which is barely readable and breaks roundtripability of the IR. This commit changes to use `EnumAttr` as the base directly so that we can have separate attribute definitions and better IR printing. Reviewed By: kuhar Differential Revision: https://reviews.llvm.org/D131311
2021-12-10[mlir][spirv] Avoid duplicated Block decoration during serializationLei Zhang1-17/+39
It's legal per the Vulkan / SPIR-V spec; still it's better to avoid such duplication to have cleaner blob and reduce the binary size. Reviewed By: scotttodd Differential Revision: https://reviews.llvm.org/D115532
2021-12-10[mlir][spirv] Add serialization control to emit symbol nameLei Zhang1-13/+50
In SPIR-V, symbol names are encoded as `OpName` instructions. They are not semantic impacting and can be omitted, which can reduce the binary size. Reviewed By: scotttodd Differential Revision: https://reviews.llvm.org/D115531
2021-06-09[mlir][spirv] Use SingleBlock + NoTerminator for spv.moduleLei Zhang1-2/+2
This allows us to remove the `spv.mlir.endmodule` op and all the code associated with it. Along the way, tightened the APIs for `spv.module` a bit by removing some aliases. Now we use `getRegion` to get the only region, and `getBody` to get the region's only block. Reviewed By: mravishankar, hanchung Differential Revision: https://reviews.llvm.org/D103265
2021-05-06[mlir][spirv] NFC: Replace OwningSPIRVModuleRef with OwningOpRefLei Zhang1-2/+1
Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D102009
2020-12-17[mlir][spirv] NFC: Shuffle code around to better follow conventionLei Zhang1-5/+5
This commit shuffles SPIR-V code around to better follow MLIR convention. Specifically, * Created IR/, Transforms/, Linking/, and Utils/ subdirectories and moved suitable code inside. * Created SPIRVEnums.{h|cpp} for SPIR-V C/C++ enums generated from SPIR-V spec. Previously they are cluttered inside SPIRVTypes.{h|cpp}. * Fixed include guards in various header files (both .h and .td). * Moved serialization tests under test/Target/SPIRV. * Renamed TableGen backend -gen-spirv-op-utils into -gen-spirv-attr-utils as it is only generating utility functions for attributes. Reviewed By: mravishankar Differential Revision: https://reviews.llvm.org/D93407
2020-12-14[MLIR][SPIRV] Refactoring serialization and deserializationergawy1-2/+2
This commit splits SPIR-V's serialization and deserialization code into separate libraries. The motiviation being that the serializer is used more often the deserializer and therefore lumping them together unnecessarily increases binary size for the most common case. This commit also moves these libraries into the Target/ directory to follow MLIR convention. Reviewed By: antiagainst Differential Revision: https://reviews.llvm.org/D91548
2020-10-24Remove global dialect registrationMehdi Amini1-1/+1
This has been deprecated for >1month now and removal was announced in: https://llvm.discourse.group/t/rfc-revamp-dialect-registration/1559/11 Differential Revision: https://reviews.llvm.org/D86356
2020-10-23Revert "Remove global dialect registration"Mehdi Amini1-1/+1
This reverts commit b22e2e4c6e420b78a8a4c307f0cf002f51af9590. Investigating broken builds
2020-10-23Remove global dialect registrationMehdi Amini1-1/+1
This has been deprecated for >1month now and removal was announced in: https://llvm.discourse.group/t/rfc-revamp-dialect-registration/1559/11 Differential Revision: https://reviews.llvm.org/D86356
2020-08-19Separate the Registration from Loading dialects in the ContextMehdi Amini1-1/+4
This changes the behavior of constructing MLIRContext to no longer load globally registered dialects on construction. Instead Dialects are only loaded explicitly on demand: - the Parser is lazily loading Dialects in the context as it encounters them during parsing. This is the only purpose for registering dialects and not load them in the context. - Passes are expected to declare the dialects they will create entity from (Operations, Attributes, or Types), and the PassManager is loading Dialects into the Context when starting a pipeline. This changes simplifies the configuration of the registration: a compiler only need to load the dialect for the IR it will emit, and the optimizer is self-contained and load the required Dialects. For example in the Toy tutorial, the compiler only needs to load the Toy dialect in the Context, all the others (linalg, affine, std, LLVM, ...) are automatically loaded depending on the optimization pipeline enabled. To adjust to this change, stop using the existing dialect registration: the global registry will be removed soon. 1) For passes, you need to override the method: virtual void getDependentDialects(DialectRegistry &registry) const {} and registery on the provided registry any dialect that this pass can produce. Passes defined in TableGen can provide this list in the dependentDialects list field. 2) For dialects, on construction you can register dependent dialects using the provided MLIRContext: `context.getOrLoadDialect<DialectName>()` This is useful if a dialect may canonicalize or have interfaces involving another dialect. 3) For loading IR, dialect that can be in the input file must be explicitly registered with the context. `MlirOptMain()` is taking an explicit registry for this purpose. See how the standalone-opt.cpp example is setup: mlir::DialectRegistry registry; registry.insert<mlir::standalone::StandaloneDialect>(); registry.insert<mlir::StandardOpsDialect>(); Only operations from these two dialects can be in the input file. To include all of the dialects in MLIR Core, you can populate the registry this way: mlir::registerAllDialects(registry); 4) For `mlir-translate` callback, as well as frontend, Dialects can be loaded in the context before emitting the IR: context.getOrLoadDialect<ToyDialect>() Differential Revision: https://reviews.llvm.org/D85622
2020-08-19Revert "Separate the Registration from Loading dialects in the Context"Mehdi Amini1-4/+1
This reverts commit d14cf45735b0d09d7d3caf0824779520dd20ef10. The build is broken with GCC-5.
2020-08-18Separate the Registration from Loading dialects in the ContextMehdi Amini1-1/+4
This changes the behavior of constructing MLIRContext to no longer load globally registered dialects on construction. Instead Dialects are only loaded explicitly on demand: - the Parser is lazily loading Dialects in the context as it encounters them during parsing. This is the only purpose for registering dialects and not load them in the context. - Passes are expected to declare the dialects they will create entity from (Operations, Attributes, or Types), and the PassManager is loading Dialects into the Context when starting a pipeline. This changes simplifies the configuration of the registration: a compiler only need to load the dialect for the IR it will emit, and the optimizer is self-contained and load the required Dialects. For example in the Toy tutorial, the compiler only needs to load the Toy dialect in the Context, all the others (linalg, affine, std, LLVM, ...) are automatically loaded depending on the optimization pipeline enabled. To adjust to this change, stop using the existing dialect registration: the global registry will be removed soon. 1) For passes, you need to override the method: virtual void getDependentDialects(DialectRegistry &registry) const {} and registery on the provided registry any dialect that this pass can produce. Passes defined in TableGen can provide this list in the dependentDialects list field. 2) For dialects, on construction you can register dependent dialects using the provided MLIRContext: `context.getOrLoadDialect<DialectName>()` This is useful if a dialect may canonicalize or have interfaces involving another dialect. 3) For loading IR, dialect that can be in the input file must be explicitly registered with the context. `MlirOptMain()` is taking an explicit registry for this purpose. See how the standalone-opt.cpp example is setup: mlir::DialectRegistry registry; registry.insert<mlir::standalone::StandaloneDialect>(); registry.insert<mlir::StandardOpsDialect>(); Only operations from these two dialects can be in the input file. To include all of the dialects in MLIR Core, you can populate the registry this way: mlir::registerAllDialects(registry); 4) For `mlir-translate` callback, as well as frontend, Dialects can be loaded in the context before emitting the IR: context.getOrLoadDialect<ToyDialect>() Differential Revision: https://reviews.llvm.org/D85622
2020-08-18Revert "Separate the Registration from Loading dialects in the Context"Mehdi Amini1-4/+1
This reverts commit e1de2b75501e5eaf8777bd5248382a7c55a44fd6. Broke a build bot.
2020-08-18Separate the Registration from Loading dialects in the ContextMehdi Amini1-1/+4
This changes the behavior of constructing MLIRContext to no longer load globally registered dialects on construction. Instead Dialects are only loaded explicitly on demand: - the Parser is lazily loading Dialects in the context as it encounters them during parsing. This is the only purpose for registering dialects and not load them in the context. - Passes are expected to declare the dialects they will create entity from (Operations, Attributes, or Types), and the PassManager is loading Dialects into the Context when starting a pipeline. This changes simplifies the configuration of the registration: a compiler only need to load the dialect for the IR it will emit, and the optimizer is self-contained and load the required Dialects. For example in the Toy tutorial, the compiler only needs to load the Toy dialect in the Context, all the others (linalg, affine, std, LLVM, ...) are automatically loaded depending on the optimization pipeline enabled. To adjust to this change, stop using the existing dialect registration: the global registry will be removed soon. 1) For passes, you need to override the method: virtual void getDependentDialects(DialectRegistry &registry) const {} and registery on the provided registry any dialect that this pass can produce. Passes defined in TableGen can provide this list in the dependentDialects list field. 2) For dialects, on construction you can register dependent dialects using the provided MLIRContext: `context.getOrLoadDialect<DialectName>()` This is useful if a dialect may canonicalize or have interfaces involving another dialect. 3) For loading IR, dialect that can be in the input file must be explicitly registered with the context. `MlirOptMain()` is taking an explicit registry for this purpose. See how the standalone-opt.cpp example is setup: mlir::DialectRegistry registry; mlir::registerDialect<mlir::standalone::StandaloneDialect>(); mlir::registerDialect<mlir::StandardOpsDialect>(); Only operations from these two dialects can be in the input file. To include all of the dialects in MLIR Core, you can populate the registry this way: mlir::registerAllDialects(registry); 4) For `mlir-translate` callback, as well as frontend, Dialects can be loaded in the context before emitting the IR: context.getOrLoadDialect<ToyDialect>()
2020-08-15Revert "Separate the Registration from Loading dialects in the Context"Mehdi Amini1-4/+1
This reverts commit 20563933875a9396c8ace9c9770ecf6a988c4ea6. Build is broken on a few bots
2020-08-15Separate the Registration from Loading dialects in the ContextMehdi Amini1-1/+4
This changes the behavior of constructing MLIRContext to no longer load globally registered dialects on construction. Instead Dialects are only loaded explicitly on demand: - the Parser is lazily loading Dialects in the context as it encounters them during parsing. This is the only purpose for registering dialects and not load them in the context. - Passes are expected to declare the dialects they will create entity from (Operations, Attributes, or Types), and the PassManager is loading Dialects into the Context when starting a pipeline. This changes simplifies the configuration of the registration: a compiler only need to load the dialect for the IR it will emit, and the optimizer is self-contained and load the required Dialects. For example in the Toy tutorial, the compiler only needs to load the Toy dialect in the Context, all the others (linalg, affine, std, LLVM, ...) are automatically loaded depending on the optimization pipeline enabled. Differential Revision: https://reviews.llvm.org/D85622
2020-08-15Revert "Separate the Registration from Loading dialects in the Context"Mehdi Amini1-4/+1
This was landed by accident, will reland with the right comments addressed from the reviews. Also revert dependent build fixes.
2020-08-14Separate the Registration from Loading dialects in the ContextMehdi Amini1-1/+4
This changes the behavior of constructing MLIRContext to no longer load globally registered dialects on construction. Instead Dialects are only loaded explicitly on demand: - the Parser is lazily loading Dialects in the context as it encounters them during parsing. This is the only purpose for registering dialects and not load them in the context. - Passes are expected to declare the dialects they will create entity from (Operations, Attributes, or Types), and the PassManager is loading Dialects into the Context when starting a pipeline. This changes simplifies the configuration of the registration: a compiler only need to load the dialect for the IR it will emit, and the optimizer is self-contained and load the required Dialects. For example in the Toy tutorial, the compiler only needs to load the Toy dialect in the Context, all the others (linalg, affine, std, LLVM, ...) are automatically loaded depending on the optimization pipeline enabled.
2020-07-16[spirv] Use owning module ref to avoid leaks and fix ASAN testsLei Zhang1-4/+5
Differential Revision: https://reviews.llvm.org/D83982
2020-06-12[mlir][spirv] Enhance structure type member decoration handlingHazemAbdelhafez1-2/+2
Modify structure type in SPIR-V dialect to support: 1) Multiple decorations per structure member 2) Key-value based decorations (e.g., MatrixStride) This commit kept the Offset decoration separate from members' decorations container for easier implementation and logical clarity. As such, all references to Structure layoutinfo are now offsetinfo, and any member layout defining decoration (e.g., RowMajor for Matrix) will be add to the members' decorations container along with its value if any. Differential Revision: https://reviews.llvm.org/D81426
2020-06-12Revert "[mlir][spirv] Enhance structure type member decoration handling"Mehdi Amini1-2/+2
This reverts commit 5d74df5b03e46b7bd3700e3595c7008a6905b288. This broke the MSVC build: <bits/stdint-uintn.h> isn't available on Windows
2020-06-11[mlir][spirv] Enhance structure type member decoration handlingHazemAbdelhafez1-2/+2
Modify structure type in SPIR-V dialect to support: 1) Multiple decorations per structure member 2) Key-value based decorations (e.g., MatrixStride) This commit kept the Offset decoration separate from members' decorations container for easier implementation and logical clarity. As such, all references to Structure layoutinfo are now offsetinfo, and any member layout defining decoration (e.g., RowMajor for Matrix) will be add to the members' decorations container along with its value if any. Differential Revision: https://reviews.llvm.org/D81426
2020-06-11Revert "[mlir][spirv] Enhance structure type member decoration handling"Mehdi Amini1-2/+2
This reverts commit 4b7aa6c8c1b0f68c6800225b39b3b389adf31332. This broke gcc builds.
2020-06-10[mlir][spirv] Enhance structure type member decoration handlingHazemAbdelhafez1-2/+2
Modify structure type in SPIR-V dialect to support: 1) Multiple decorations per structure member 2) Key-value based decorations (e.g., MatrixStride) This commit kept the Offset decoration separate from members' decorations container for easier implementation and logical clarity. As such, all references to Structure layoutinfo are now offsetinfo, and any member layout defining decoration (e.g., RowMajor for Matrix) will be add to the members' decorations container along with its value if any. Differential Revision: https://reviews.llvm.org/D81426
2020-04-28[mlir][flang] use OpBuilder& instead of Builder* in <Op>::build methodsAlex Zinenko1-2/+2
As we start defining more complex Ops, we increasingly see the need for Ops-with-regions to be able to construct Ops within their regions in their ::build methods. However, these methods only have access to Builder, and not OpBuilder. Creating a local instance of OpBuilder inside ::build and using it fails to trigger the operation creation hooks in derived builders (e.g., ConversionPatternRewriter). In this case, we risk breaking the logic of the derived builder. At the same time, OpBuilder::create, which is by far the largest user of ::build already passes "this" as the first argument, so an OpBuilder instance is already available. Update all ::build methods in all Ops in MLIR and Flang to take "OpBuilder &" instead of "Builder *". Note the change from pointer and to reference to comply with the common style in MLIR, this also ensures all other users must change their ::build methods. Differential Revision: https://reviews.llvm.org/D78713
2020-03-12[mlir][spirv] Use spv.vce in spv.module and wire up (de)serializationLei Zhang1-0/+5
This commits changes the definition of spv.module to use the #spv.vce attribute for specifying (version, capabilities, extensions) triple so that we can have better API and custom assembly form. Since now we have proper modelling of the triple, (de)serialization is wired up to use them. With the new UpdateVCEPass, we don't need to manually specify the required extensions and capabilities anymore when creating a spv.module. One just need to call UpdateVCEPass before serialization to get the needed version/extensions/capabilities. Differential Revision: https://reviews.llvm.org/D75872
2020-01-26Mass update the MLIR license header to mention "Part of the LLVM project"Mehdi Amini1-1/+1
This is an artifact from merging MLIR into LLVM, the file headers are now aligned with the rest of the project.
2019-12-23Adjust License.txt file to use the LLVM licenseMehdi Amini1-13/+4
PiperOrigin-RevId: 286906740
2019-10-20Fix minor spelling tweaks (NFC)Kazuaki Ishizaki1-1/+1
Closes tensorflow/mlir#175 PiperOrigin-RevId: 275726876
2019-10-17NFC: Remove trivial builder get methods.River Riddle1-1/+1
These don't add any value, and some are even more restrictive than the respective static 'get' method. PiperOrigin-RevId: 275391240
2019-09-20NFC: Pass OperationState by reference instead of by pointer.River Riddle1-1/+1
MLIR follows the LLVM convention of passing by reference instead of by pointer. PiperOrigin-RevId: 270396945
2019-08-27[spirv] Add Block decoration for spv.struct.Denis Khalikov1-0/+124
Add Block decoration for top-level spv.struct. Closes tensorflow/mlir#102 PiperOrigin-RevId: 265716241
generated by cgit v1.1 at 2025-08-02 22:16:05 +0000