summaryrefslogtreecommitdiffstats
path: root/mlir/lib/Dialect/SPIRV
Commit message (Collapse)AuthorAgeFilesLines
...
* [spirv] Add AccessChainOp operation.Denis Khalikov2019-07-251-0/+138
| | | | | | | | | AccessChainOp creates a pointer into a composite object that can be used with OpLoad and OpStore. Closes tensorflow/mlir#52 PiperOrigin-RevId: 260035676
* (De)serialize composite spv.constantLei Zhang2019-07-222-5/+382
| | | | | | | This CL covers the case of composite spv.constant. We encode/decode them into/from OpConstantComposite/OpConstantNull. PiperOrigin-RevId: 259394700
* (De)serialize float scalar spv.constantLei Zhang2019-07-222-2/+77
| | | | | | This CL adds support for float scalar spv.constant in (de)serialization. PiperOrigin-RevId: 259311776
* (De)serialize bool and integer scalar spv.constantLei Zhang2019-07-222-34/+325
| | | | | | | | | | | | | | | | | | | | | SPIR-V has multiple constant instructions covering different constant types: * `OpConstantTrue` and `OpConstantFalse` for boolean constants * `OpConstant` for scalar constants * `OpConstantComposite` for composite constants * `OpConstantNull` for null constants * ... We model them all with a single spv.constant op for uniformity and friendliness to transformations. This does mean that when doing (de)serialization, we need to poke spv.constant's type to determine which SPIR-V binary instruction to use. This CL only covers the case of bool and integer spv.constant. The rest will follow. PiperOrigin-RevId: 259311698
* [spirv] NFC: adjust `encode*` function signatures in SerializerLei Zhang2019-07-221-26/+29
| | | | | | | | | * Let them return `LogicalResult` so we can chain them together with other functions returning `LogicalResult`. * Added "Into" as the suffix to the function name and made the `binary` as the first parameter so that it reads more naturally. PiperOrigin-RevId: 259311636
* [spirv] Remove one level of indirection: processOp to processOpImplLei Zhang2019-07-222-11/+2
| | | | | | | | | | | We already have two levels of controls in SPIRVBase.td: hasOpcode and autogenSerialization. The former controls whether to add an entry to the dispatch table, while the latter controls whether to autogenerate the op's (de)serialization method specialization. This is enough for our cases. Remove the indirection from processOp to processOpImpl to simplify the picture. PiperOrigin-RevId: 259308711
* Add (de)serialization of EntryPointOp and ExecutionModeOpMahesh Ravishankar2019-07-202-38/+261
| | | | | | | | | Since the serialization of EntryPointOp contains the name of the function as well, the function serialization emits the function name using OpName instruction, which is used during deserialization to get the correct function name. PiperOrigin-RevId: 259158784
* [spirv] Avoid printing duplicate trailing typeLei Zhang2019-07-191-2/+4
| | | | | | | | | When printing the value attribute in spv.constant, OpAsmPrinter already attaches a trailing type. So we don't need to duplicate it again unless it's an array attribute, which does not have type by default but we use it for spirv::ArrayType. PiperOrigin-RevId: 258994197
* Replace bitwiseCast with llvm::bit_castLei Zhang2019-07-191-12/+5
| | | | PiperOrigin-RevId: 258986485
* Wrap op (de)serialization methods in anonymous namespaceLei Zhang2019-07-192-0/+4
| | | | | | | | | | | | It's a known bug that older GCC is not happy with method specialization in the enclosing (global) namespace: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56480 This CL wraps the generated specialization methods in the anonymous namespace to make sure the specialization is in the same namespace as the class. PiperOrigin-RevId: 258983181
* Make SPIR-V spv.EntryPoint and spv.ExecutionMode consistent with SPIR-V specMahesh Ravishankar2019-07-193-28/+6
| | | | | | | | | | | | | This CL changes the Op definition of spirv::EntryPointOp and spirv::ExecutionModeOp to be consistent with the SPIR-V spec. 1) The EntryPointOp doesn't return a value 2) The ExecutionModeOp takes as argument, the SymbolRefAttr to refer to the function, instead of the result of the EntryPointOp. Following this, the spirv::EntryPointType is no longer necessary, and is removed. PiperOrigin-RevId: 258964027
* [spirv] group methods better and improve commentsLei Zhang2019-07-192-253/+310
| | | | | | | | This CL groups (de)serialization methods logically and improves comments at various places. It also sorted method implementations to follow the order of their declarations. There is NFC. PiperOrigin-RevId: 258843490
* Automatically generate (de)serialization methods for SPIR-V opsMahesh Ravishankar2019-07-193-38/+118
| | | | | | | | | | | | | | | | For ops in SPIR-V dialect that are a direct mirror of SPIR-V operations, the serialization/deserialization methods can be automatically generated from the Op specification. To enable this an 'autogenSerialization' field is added to SPV_Ops. When set to non-zero, this will enable the automatic (de)serialization function generation Also adding tests that verify the spv.Load, spv.Store and spv.Variable ops are serialized and deserialized correctly. To fully support these tests also add serialization and deserialization of float types and spv.ptr types PiperOrigin-RevId: 258684764
* NFC: Move SPIR-V dialect to Dialect/ subdirectoryLei Zhang2019-07-1611-0/+2896
PiperOrigin-RevId: 258345603
OpenPOWER on IntegriCloud