summaryrefslogtreecommitdiffstats
path: root/mlir/lib/Dialect/SPIRV/Serialization
Commit message (Collapse)AuthorAgeFilesLines
...
* [spirv] Add support for extension (de)serializationLei Zhang2019-08-222-2/+57
| | | | | | | Only a few important KHR extensions are registered to the SPIR-V dialect for now. PiperOrigin-RevId: 264939428
* [spirv] Add support for capability (de)serializationLei Zhang2019-08-222-4/+61
| | | | | | | This CL pulls in capabilities defined in the spec and adds support for (de)serialize capabilities of a spv.module. PiperOrigin-RevId: 264877413
* Remove the wrapping function in SPIR-V (de)serializationLei Zhang2019-08-212-35/+6
| | | | | | | | | Previously Module and Function are builtinn constructs in MLIR. Due to the structural requirements we must wrap the SPIR-V module inside a Function inside a Module. Now the requirement is lifted and we can remove the wrapping function! :) PiperOrigin-RevId: 264736051
* Materialize spv.constants at use sitesLei Zhang2019-08-211-58/+70
| | | | | | | | | | | | | | | In SPIR-V binary format, constants are placed at the module level and referenced by instructions inside functions using their result <id>s. To model this natively (using SSA values for result <id>s), it means we need to have implicit capturing functions. We will lose the ability to have function passes if going down that path. Instead, this CL changes to materialize constants at their use sites in deserialization. It's cheap to copy constants in MLIR given that attributes is uniqued to MLIRContext. By localizing constants into functions, we can preserve isolated functions. PiperOrigin-RevId: 264582532
* Add spv.specConstant and spv._reference_ofLei Zhang2019-08-202-136/+248
| | | | | | | | | | | | | | | | | | | | | | | | | | | Similar to global variables, specialization constants also live in the module scope and can be referenced by instructions in functions in native SPIR-V. A direct modelling would be to allow functions in the SPIR-V dialect to implicit capture, but it means we are losing the ability to write passes for Functions. While in SPIR-V normally we want to process the module as a whole, it's not common to see multiple functions get used so we'd like to leave the door open for those cases. Therefore, similar to global variables, we introduce spv.specConstant to model three SPIR-V instructions: OpSpecConstantTrue, OpSpecConstantFalse, and OpSpecConstant. They do not return SSA value results; instead they have symbols and can only be referenced by the symbols. To use it in a function, we need to have another op spv._reference_of to turn the symbol into an SSA value. This breaks the tie and makes functions still explicit capture. Previously specialization constants were handled similarly as normal constants. That is incorrect given that specialization constant actually acts more like variable (without need to load and store). E.g., they cannot be de-duplicated like normal constants. This CL also refines various documents and comments. PiperOrigin-RevId: 264455172
* [spirv] Support (de)serialization of spv.structDenis Khalikov2019-08-202-0/+112
| | | | | | | | Support (de)serialization of spv.struct with offset decorations. Closes tensorflow/mlir#94 PiperOrigin-RevId: 264421427
* NFC: Move LLVMIR, SDBM, and StandardOps to the Dialect/ directory.River Riddle2019-08-191-1/+1
| | | | PiperOrigin-RevId: 264193915
* Add spirv::GlobalVariableOp that allows module level definition of variablesMahesh Ravishankar2019-08-172-17/+213
| | | | | | | | | | | | | | | | | | | | FuncOps in MLIR use explicit capture. So global variables defined in module scope need to have a symbol name and this should be used to refer to the variable within the function. This deviates from SPIR-V spec, which assigns an SSA value to variables at all scopes that can be used to refer to the variable, which requires SPIR-V functions to allow implicit capture. To handle this add a new op, spirv::GlobalVariableOp that can be used to define module scope variables. Since instructions need an SSA value, an new spirv::AddressOfOp is added to convert a symbol reference to an SSA value for use with other instructions. This also means the spirv::EntryPointOp instruction needs to change to allow initializers to be specified using symbol reference instead of SSA value The current spirv::VariableOp which returns an SSA value (as defined by SPIR-V spec) can still be used to define function-scope variables. PiperOrigin-RevId: 263951109
* [spirv] Extend spv.array with LayoutinfoDenis Khalikov2019-08-162-6/+39
| | | | | | | | Extend spv.array with Layoutinfo to support (de)serialization. Closes tensorflow/mlir#80 PiperOrigin-RevId: 263795304
* Add BuiltIn EnumAttr to SPIR-V dialectMahesh Ravishankar2019-08-152-0/+20
| | | | | | | | | | Generate the EnumAttr to represent BuiltIns in SPIR-V dialect. The builtIn can be specified as a StringAttr with value being the name of the builtin. Extend Decoration (de)serialization to handle BuiltIns. Also fix an error in the SPIR-V dialect generator script. PiperOrigin-RevId: 263596624
* Refactor ElementsAttr::getValue and DenseElementsAttr::getSplatValue.River Riddle2019-08-141-22/+20
| | | | | | All 'getValue' variants now require that the index is valid, queryable via 'isValidIndex'. 'getSplatValue' now requires that the attribute is a proper splat. This allows for querying these methods on DenseElementAttr with all possible value types; e.g. float, int, APInt, etc. This also allows for removing unnecessary conversions to Attribute that really want the underlying value. PiperOrigin-RevId: 263437337
* NFC: Update FuncOp::addEntryBlock to return the newly inserted block.River Riddle2019-08-071-2/+1
| | | | | | The entry block is often used recently after insertion. This removes the need to perform an additional lookup in such cases. PiperOrigin-RevId: 262265671
* Initialize local variables for opcode to fix MSAN failuresLei Zhang2019-08-071-3/+3
| | | | PiperOrigin-RevId: 262225919
* [spirv] Add support for specialization constantLei Zhang2019-08-012-85/+138
| | | | | | | | This CL extends the existing spv.constant op to also support specialization constant by adding an extra unit attribute on it. PiperOrigin-RevId: 261194869
* Add support for (de)serialization of SPIR-V Op DecorationsMahesh Ravishankar2019-07-302-0/+74
| | | | | | | | | | | | All non-argument attributes specified for an operation are treated as decorations on the result value and (de)serialized using OpDecorate instruction. An error is generated if an attribute is not an argument, and the name doesn't correspond to a Decoration enum. Name of the attributes that represent decoerations are to be the snake-case-ified version of the Decoration name. Add utility methods to convert to snake-case and camel-case. PiperOrigin-RevId: 260792638
* [spirv] Add basic infrastructure for negative deserializer testsLei Zhang2019-07-305-99/+93
| | | | | | | | | | | | | We are relying on serializer to construct positive cases to drive the test for deserializer. This leaves negative cases untested. This CL adds a basic test fixture for covering the negative corner cases to enforce a more robust deserializer. Refactored common SPIR-V building methods out of serializer to share it with the deserialization test. PiperOrigin-RevId: 260742733
* (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
* 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
* [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-166-0/+1003
PiperOrigin-RevId: 258345603
OpenPOWER on IntegriCloud