summaryrefslogtreecommitdiffstats
path: root/mlir/test/Dialect/SPIRV
Commit message (Collapse)AuthorAgeFilesLines
...
* Add spv.Undef op to support OpUndef instruction in SPIR-V.Mahesh Ravishankar2019-10-042-0/+44
| | | | | | | | Adding support for OpUndef instruction. Updating the dialect generation script to fix a few bugs in the instruction spec generation. PiperOrigin-RevId: 272975685
* [spirv] Add support for spv.selectionLei Zhang2019-10-022-3/+169
| | | | | | | | | | | | | | | Similar to spv.loop, spv.selection is another op for modelling SPIR-V structured control flow. It covers both OpBranchConditional and OpSwitch with OpSelectionMerge. Instead of having a `spv.SelectionMerge` op to directly model selection merge instruction for indicating the merge target, we use regions to delimit the boundary of the selection: the merge target is the next op following the `spv.selection` op. This way it's easier to discover all blocks belonging to the selection and it plays nicer with the MLIR system. PiperOrigin-RevId: 272475006
* [spirv] Add array length check.Denis Khalikov2019-09-301-0/+5
| | | | | | | | | | According to the SPIR-V spec: "Length is the number of elements in the array. It must be at least 1." Closes tensorflow/mlir#160 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/160 from denis0x0D:sandbox/array_len 0840dc0986ad0088a3aa7d5d8d3e97d489377ed9 PiperOrigin-RevId: 272094669
* Add support for Logical Ops in SPIR-V dialectMahesh Ravishankar2019-09-301-0/+107
| | | | | | | | | | | | | | | | | | Add operations corresponding to OpLogicalAnd, OpLogicalNot, OpLogicalEqual, OpLogicalNotEqual and OpLogicalOr instructions in SPIR-V dialect. This needs changes to class hierarchy in SPIR-V TableGen files to split SPIRVLogicalOp into SPIRVLogicalUnaryOp and SPIRVLogicalBinaryOp. All derived classes of SPIRVLogicalOp are updated accordingly. Update the spirv dialect generation script to 1) Allow specifying base class to use for instruction spec generation and file name to generate the specification in separately. 2) Use the existing descriptions for operations. 3) Update define_inst.sh to also invoke define_opcode.sh to also define the corresponding SPIR-V instruction opcode enum. PiperOrigin-RevId: 272014876
* Add spv.Bitcast operation to SPIR-V dialectMahesh Ravishankar2019-09-252-0/+91
| | | | | | | | | Support the OpBitcast instruction of SPIR-V using the spv.Bitcast operation. The semantics implemented in the dialect differ from the SPIR-V spec in that the dialect does not allow conversion to/from pointer types from/to non-pointer types. PiperOrigin-RevId: 271255957
* [spirv] Add SPV_UnaryOp and spv.FNegateLei Zhang2019-09-252-0/+17
| | | | | | | This CL also moves common parsers and printers to the same section in SPIRVOps.cpp. PiperOrigin-RevId: 271233546
* Add support for GLSL Binary ops, and use it to implement GLSL FMax.Mahesh Ravishankar2019-09-242-1/+27
| | | | | | | | A base class is added to implement all GLSL Binary operations and is used to implement the FMax operation. The existing framework already generates all the necessary (de)serialization code. PiperOrigin-RevId: 271037166
* [spirv] NFC: clean up (de)serialization testsLei Zhang2019-09-2321-167/+179
| | | | | | | | This CL uses the newly added -split-input-file CLI option to mlir-translate to combine certain (de)serialization tests. It also renames certain test filenames. PiperOrigin-RevId: 270816324
* Make spirv::RuntimeArrayType part of spirv::CompositeType.Mahesh Ravishankar2019-09-231-0/+8
| | | | | | | According to SPIR-V spec, spirv::CompositeType includes spirv::RuntimeArrayType. This allows using objects of spirv::RuntimeArrayType with spirv::AccessChainOp. PiperOrigin-RevId: 270809492
* Handle OpMemberName instruction in SPIR-V deserializer.Mahesh Ravishankar2019-09-231-6/+0
| | | | | | | | | | Sdd support in deserializer for OpMemberName instruction. For now the name is just processed and not associated with the spirv::StructType being built. That needs an enhancement to spirv::StructTypes itself. Add tests to check for errors reported during deserialization with some refactoring to common out some utility functions. PiperOrigin-RevId: 270794524
* Simplify the way spirv::StructTypes are parsed.Mahesh Ravishankar2019-09-232-15/+45
| | | | | | | | | | | | | The existing logic to parse spirv::StructTypes is very brittle. This change simplifies the parsing logic a lot. The simplification also allows for memberdecorations to be separated by commas instead of spaces (which was an artifact of the existing parsing logic). The change also needs a modification to mlir::parseType to return the number of chars parsed. Adding a new parseType method to do so. Also allow specification of spirv::StructType with no members. PiperOrigin-RevId: 270739672
* [spirv] Add OpControlBarrier and OpMemoryBarrier.Denis Khalikov2019-09-212-0/+72
| | | | | | | | | Add OpControlBarrier and OpMemoryBarrier (de)serialization. Closes tensorflow/mlir#130 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/130 from denis0x0D:sandbox/memory_barrier 2e3fff16bca44904dc1039592cb9a65d526faea8 PiperOrigin-RevId: 270457478
* Allow specification of decorators on SPIR-V StructType members.Mahesh Ravishankar2019-09-192-2/+44
| | | | | | | | | | Allow specification of decorators on SPIR-V StructType members. If the struct has layout information, these decorations are to be specified after the offset specification of the member. These decorations are emitted as OpMemberDecorate instructions on the struct <id>. Update (de)serialization to handle these decorations. PiperOrigin-RevId: 270130136
* Add (de)serialization support for OpRuntimeArray.Mahesh Ravishankar2019-09-171-0/+8
| | | | | | Update the SPIR-V (de)serialization to handle RuntimeArrayType. PiperOrigin-RevId: 269667196
* Register a -test-spirv-roundtrip hook to mlir-translateLei Zhang2019-09-1721-21/+21
| | | | | | | | | | This CL registers a new mlir-translate hook, -test-spirv-roundtrip, for testing SPIR-V serialization and deserialization round-trip. This CL also moves the existing -serialize-spirv and -deserialize-spirv hooks to one source file. PiperOrigin-RevId: 269659528
* Autogenerate (de)serialization for Extended Instruction SetsMahesh Ravishankar2019-09-162-9/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | A generic mechanism for (de)serialization of extended instruction sets is added with this CL. To facilitate this, a new class "SPV_ExtendedInstSetOp" is added which is a base class for all operations corresponding to extended instruction sets. The methods to (de)serialization such ops as well as its dispatch is generated automatically. The behavior controlled by autogenSerialization and hasOpcode is also slightly modified to enable this. They are now decoupled. 1) Setting hasOpcode=1 means the operation has a corresponding opcode in SPIR-V binary format, and its dispatch for (de)serialization is automatically generated. 2) Setting autogenSerialization=1 generates the function for (de)serialization automatically. So now it is possible to have hasOpcode=0 and autogenSerialization=1 (for example SPV_ExtendedInstSetOp). Since the dispatch functions is also auto-generated, the input file needs to contain all operations. To this effect, SPIRVGLSLOps.td is included into SPIRVOps.td. This makes the previously added SPIRVGLSLOps.h and SPIRVGLSLOps.cpp unnecessary, and are deleted. The SPIRVUtilsGen.cpp is also changed to make better use of formatv,making the code more readable. PiperOrigin-RevId: 269456263
* [spirv] Add support for function calls.Denis Khalikov2019-09-162-0/+158
| | | | | | | | | Add spv.FunctionCall operation and (de)serialization. Closes tensorflow/mlir#137 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/137 from denis0x0D:sandbox/function_call_op e2e6f07d21e7f23e8b44c7df8a8ab784f3356ce4 PiperOrigin-RevId: 269437167
* [spirv] Add support for BitEnumAttrLei Zhang2019-09-161-6/+78
| | | | | | | | | | | | | | | | | | | | Certain enum classes in SPIR-V, like function/loop control and memory access, are bitmasks. This CL introduces a BitEnumAttr to properly model this and drive auto-generation of verification code and utility functions. We still store the attribute using an 32-bit IntegerAttr for minimal memory footprint and easy (de)serialization. But utility conversion functions are adjusted to inspect each bit and generate "|"-concatenated strings for the bits; vice versa. Each such enum class has a "None" case that means no bit is set. We need special handling for "None". Because of this, the logic is not general anymore. So right now the definition is placed in the SPIR-V dialect. If later this turns out to be useful for other dialects, then we can see how to properly adjust it and move to OpBase.td. Added tests for SPV_MemoryAccess to check and demonstrate. PiperOrigin-RevId: 269350620
* Add mechanism to specify extended instruction sets in SPIR-V.Mahesh Ravishankar2019-09-151-0/+49
| | | | | | | | | | | | | | | | | | Add support for specifying extended instructions sets. The operations in SPIR-V dialect are named as 'spv.<extension-name>.<op-name>'. Use this mechanism to define a 'Exp' operation from GLSL(450) instructions. Later CLs will add support for (de)serialization of these operations, and update the dialect generation scripts to auto-generate the specification using the spec directly. Additional changes: Add a Type Constraint to OpBase.td to check for vector of specified lengths. This is used to check that the vector type used in SPIR-V dialect are of lengths 2, 3 or 4. Update SPIRVBase.td to use this Type constraints for vectors. PiperOrigin-RevId: 269234377
* Update SPIR-V symbols and use GLSL450 instead of VulkanKHRLei Zhang2019-09-1316-50/+50
| | | | | | | | | | | | | | SPIR-V recently publishes v1.5, which brings a bunch of symbols into core. So the suffix "KHR"/"EXT"/etc. is removed from the symbols. We use a script to pull information from the spec directly. Also changed conversion and tests to use GLSL450 instead of VulkanKHR memory model. GLSL450 is still the main memory model supported by Vulkan shaders and it does not require extra capability to enable. PiperOrigin-RevId: 268992661
* [spirv] Add support for spv.loop (de)serializationLei Zhang2019-09-111-0/+59
| | | | | | | | This CL adds support for serializing and deserializing spv.loop ops. This adds support for spv.Branch and spv.BranchConditional op (de)serialization, too, because they are needed for spv.loop. PiperOrigin-RevId: 268536962
* Add folding rule for spv.CompositeExtractLei Zhang2019-09-101-0/+41
| | | | | | | | If the composite is a constant, we can fold it away. This only supports vector and array constants for now, given that struct constant is not supported in spv.constant yet. PiperOrigin-RevId: 268350340
* [spirv] Add spv.loopLei Zhang2019-09-051-0/+184
| | | | | | | | | | | | | | | | | | | | SPIR-V can explicitly declare structured control-flow constructs using merge instructions. These explicitly declare a header block before the control flow diverges and a merge block where control flow subsequently converges. These blocks delimit constructs that must nest, and can only be entered and exited in structured ways. Instead of having a `spv.LoopMerge` op to directly model loop merge instruction for indicating the merge and continue target, we use regions to delimit the boundary of the loop: the merge target is the next op following the `spv.loop` op and the continue target is the block that has a back-edge pointing to the entry block inside the `spv.loop`'s region. This way it's easier to discover all blocks belonging to a construct and it plays nicer with the MLIR system. Updated the SPIR-V.md doc. PiperOrigin-RevId: 267431010
* Add folding rule and dialect materialization hook for spv.constantLei Zhang2019-09-032-1/+36
| | | | | | | | | This will allow us to use MLIR's folding infrastructure to deduplicate SPIR-V constants. This CL also changed isValidSPIRVType in SPIRVDialect to a static method. PiperOrigin-RevId: 266984403
* Add Select operation to SPIR-V dialect.Mahesh Ravishankar2019-09-023-3/+127
| | | | | | The SelectOp models the semantics of OpSelect from SPIR-V spec. PiperOrigin-RevId: 266849559
* Add spv.Branch and spv.BranchConditionalLei Zhang2019-08-301-0/+144
| | | | | | | | This CL just covers the op definition, its parsing, printing, and verification. (De)serialization is to be implemented in a subsequent CL. PiperOrigin-RevId: 266431077
* [spirv] NFC: move SPIR-V control flow ops to a separate fileLei Zhang2019-08-232-56/+56
| | | | | | This CL is also purely moving code around for better file organization. PiperOrigin-RevId: 265092566
* [spirv] NFC: move arithmetic and logical ops to separate filesLei Zhang2019-08-233-324/+325
| | | | | | This is purely moving code around for better file organization. PiperOrigin-RevId: 265082517
* [spirv] Add support for extension (de)serializationLei Zhang2019-08-222-0/+16
| | | | | | | 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-0/+15
| | | | | | | This CL pulls in capabilities defined in the spec and adds support for (de)serialize capabilities of a spv.module. PiperOrigin-RevId: 264877413
* Point to spv.AccessChain when reporting spv.AccessChain errorsLei Zhang2019-08-211-7/+7
| | | | PiperOrigin-RevId: 264742130
* Remove the wrapping function in SPIR-V (de)serializationLei Zhang2019-08-2115-453/+406
| | | | | | | | | 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
* [spirv] Support i1 as bool typeLei Zhang2019-08-212-5/+12
| | | | PiperOrigin-RevId: 264612014
* Materialize spv.constants at use sitesLei Zhang2019-08-212-90/+163
| | | | | | | | | | | | | | | 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-203-52/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-201-0/+24
| | | | | | | | Support (de)serialization of spv.struct with offset decorations. Closes tensorflow/mlir#94 PiperOrigin-RevId: 264421427
* Fix parsing/printing of spv.globalVariable and spv._address_ofMahesh Ravishankar2019-08-196-185/+218
| | | | | | | | | | | | Change the prining/parsing of spv.globalVariable to print the type of the variable after the ':' to be consistent with MLIR convention. The spv._address_of should print the variable type after the ':'. It was mistakenly printing the address of the return value. Add a (missing) test that should have caught that. Also move spv.globalVariable and spv._address_of tests to structure-ops.mlir. PiperOrigin-RevId: 264204686
* [spirv] Add spv.ReturnValueLei Zhang2019-08-193-4/+72
| | | | | | | | | This CL adds the spv.ReturnValue op and its tests. Also adds a InFunctionScope trait to make sure that the op stays inside a function. To be consistent, ModuleOnly trait is changed to InModuleScope. PiperOrigin-RevId: 264193081
* Add spirv::GlobalVariableOp that allows module level definition of variablesMahesh Ravishankar2019-08-174-60/+155
| | | | | | | | | | | | | | | | | | | | 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-1/+22
| | | | | | | | 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/+12
| | | | | | | | | | 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
* Use SingleBlockImplicitTerminator trait for spv.moduleLei Zhang2019-08-051-2/+11
| | | | | | | | This trait provides the ensureTerminator() utility function and the checks to make sure a spv.module is indeed terminated with spv._module_end. PiperOrigin-RevId: 261664153
* [spirv] Add support for specialization constantLei Zhang2019-08-011-0/+47
| | | | | | | | This CL extends the existing spv.constant op to also support specialization constant by adding an extra unit attribute on it. PiperOrigin-RevId: 261194869
* [spirv] Add binary logical operations.Denis Khalikov2019-08-012-19/+195
| | | | | | | | | | | Add binary logical operations regarding to the spec section 3.32.15: OpIEqual, OpINotEqual, OpUGreaterThan, OpSGreaterThan, OpUGreaterThanEqual, OpSGreaterThanEqual, OpULessThan, OpSLessThan, OpULessThanEqual, OpSLessThanEqual. Closes tensorflow/mlir#61 PiperOrigin-RevId: 261181281
* Use operand number during serialization to get the <id>s of the operandsMahesh Ravishankar2019-07-311-0/+11
| | | | | | | | | | | During serialization, the operand number must be used to get the values assocaited with an operand. Using the argument number in Op specification was wrong since some of the elements in the arguments list might be attributes on the operation. This resulted in a segfault during serialization. Add a test that exercise that path. PiperOrigin-RevId: 260977758
* [spirv] Add binary arithmetic operations tensorflow/mlir#2.Denis Khalikov2019-07-312-0/+85
| | | | | | | | | Add binary operations such as: OpUdiv, OpSDiv, OpUMod, OpSRem, OpSMod. Closes tensorflow/mlir#56 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/56 from denis0x0D:sandbox/bin_ops_int 4959325a693b4658b978a8b97f79b8237eb39764 PiperOrigin-RevId: 260961681
* Add support for (de)serialization of SPIR-V Op DecorationsMahesh Ravishankar2019-07-301-4/+4
| | | | | | | | | | | | 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
* Initial implementation to translate kernel fn in GPU Dialect to SPIR-V DialectMahesh Ravishankar2019-07-302-12/+1
| | | | | | | | | | | | | | | This CL adds an initial implementation for translation of kernel function in GPU Dialect (used with a gpu.launch_kernel) op to a spv.Module. The original function is translated into an entry function. Most of the heavy lifting is done by adding TypeConversion and other utility functions/classes that provide most of the functionality to translate from Standard Dialect to SPIR-V Dialect. These are intended to be reusable in implementation of different dialect conversion pipelines. Note : Some of the files for have been renamed to be consistent with the norm used by the other Conversion frameworks. PiperOrigin-RevId: 260759165
* [spirv] Add binary arithmetic operations.Denis Khalikov2019-07-302-0/+148
| | | | | | | | | Add binary operations such as: OpIAdd, OpFAdd, OpISub, OpFSub, OpIMul, OpFDiv, OpFRem, OpFMod. Closes tensorflow/mlir#54 PiperOrigin-RevId: 260734166
* Enable (de)serialization support for spirv::AccessChainOpMahesh Ravishankar2019-07-301-0/+15
| | | | | | | | | | Automatic generation of spirv::AccessChainOp (de)serialization needs the (de)serialization emitters to handle argument specified as Variadic<...>. To handle this correctly, this argument can only be the last entry in the arguments list. Add a test to (de)serialize spirv::AccessChainOp PiperOrigin-RevId: 260532598
OpenPOWER on IntegriCloud