summaryrefslogtreecommitdiffstats
path: root/mlir/lib/Dialect/SPIRV
Commit message (Collapse)AuthorAgeFilesLines
...
* Add variants of interleave that take separatorJacques Pienaar2019-09-231-3/+1
| | | | | | Make the common case of string separator easier to specify. PiperOrigin-RevId: 270697581
* Fix a number of Clang-Tidy warnings.Christian Sigg2019-09-231-1/+1
| | | | PiperOrigin-RevId: 270632324
* [spirv] Add OpControlBarrier and OpMemoryBarrier.Denis Khalikov2019-09-213-11/+186
| | | | | | | | | 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
* NFC: Pass OpAsmPrinter by reference instead of by pointer.River Riddle2019-09-201-123/+123
| | | | | | MLIR follows the LLVM style of pass-by-reference. PiperOrigin-RevId: 270401378
* NFC: Pass OperationState by reference instead of by pointer.River Riddle2019-09-202-103/+101
| | | | | | MLIR follows the LLVM convention of passing by reference instead of by pointer. PiperOrigin-RevId: 270396945
* NFC: Pass OpAsmParser by reference instead of by pointer.River Riddle2019-09-201-173/+172
| | | | | | MLIR follows the LLVM style of pass-by-reference. PiperOrigin-RevId: 270315612
* Allow specification of decorators on SPIR-V StructType members.Mahesh Ravishankar2019-09-194-107/+226
| | | | | | | | | | 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 support to OpAsmParser for parsing unknown keywords.River Riddle2019-09-171-3/+2
| | | | | | This is useful in several cases, for example a user may want to sugar the syntax of a string(as we do with custom operation syntax), or avoid many nested ifs for parsing a set of known keywords. PiperOrigin-RevId: 269695451
* Add (de)serialization support for OpRuntimeArray.Mahesh Ravishankar2019-09-172-0/+31
| | | | | | Update the SPIR-V (de)serialization to handle RuntimeArrayType. PiperOrigin-RevId: 269667196
* Register a -test-spirv-roundtrip hook to mlir-translateLei Zhang2019-09-174-134/+158
| | | | | | | | | | 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
* Change MLIR translation functions signatureLei Zhang2019-09-172-28/+15
| | | | | | | | | | This CL changes translation functions to take MemoryBuffer as input and raw_ostream as output. It is generally better to avoid handling files directly in a library (unless the library is specifically for file manipulation) and we can unify all file handling to the mlir-translate binary itself. PiperOrigin-RevId: 269625911
* Autogenerate (de)serialization for Extended Instruction SetsMahesh Ravishankar2019-09-166-72/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-163-6/+206
| | | | | | | | | 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-163-4/+7
| | | | | | | | | | | | | | | | | | | | 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-153-0/+67
| | | | | | | | | | | | | | | | | | 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
* [spirv] Add support for spv.loop (de)serializationLei Zhang2019-09-113-50/+696
| | | | | | | | 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-1/+34
| | | | | | | | 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/+137
| | | | | | | | | | | | | | | | | | | | 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-6/+41
| | | | | | | | | 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-021-0/+58
| | | | | | The SelectOp models the semantics of OpSelect from SPIR-V spec. PiperOrigin-RevId: 266849559
* Add spv.Branch and spv.BranchConditionalLei Zhang2019-08-301-0/+115
| | | | | | | | 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] Fix the entry block to start with OpLabelLei Zhang2019-08-272-2/+51
| | | | | | | | Each basic block in SPIR-V must start with an OpLabel instruction. We don't support control flow yet, so this CL just makes sure that the entry block follows this rule and is valid. PiperOrigin-RevId: 265718841
* Enhance GPU To SPIR-V conversion to support builtins and load/store ops.Mahesh Ravishankar2019-08-271-1/+8
| | | | | | | | | | | | | | | | | To support a conversion of a simple load-compute-store kernel from GPU dialect to SPIR-V dialect, the conversion of operations like "gpu.block_dim", "gpu.thread_id" which allow threads to get the launch conversion is needed. In SPIR-V these are specified as global variables with builin attributes. This CL adds support to specify builtin variables in SPIR-V conversion framework. This is used to convert the relevant operations from GPU dialect to SPIR-V dialect. Also add support for conversion of load/store operation in Standard dialect to SPIR-V dialect. To simplify the conversion add a method to build a spv.AccessChain operation that automatically determines the return type based on the base pointer type and the indices provided. PiperOrigin-RevId: 265718525
* [spirv] Add Block decoration for spv.struct.Denis Khalikov2019-08-272-0/+38
| | | | | | | | Add Block decoration for top-level spv.struct. Closes tensorflow/mlir#102 PiperOrigin-RevId: 265716241
* [spirv] NFC: move SPIR-V control flow ops to a separate fileLei Zhang2019-08-231-7/+7
| | | | | | This CL is also purely moving code around for better file organization. PiperOrigin-RevId: 265092566
* [spirv] Add support for extension (de)serializationLei Zhang2019-08-223-2/+67
| | | | | | | 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-223-4/+72
| | | | | | | 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-2/+1
| | | | PiperOrigin-RevId: 264742130
* 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
* [spirv] Support i1 as bool typeLei Zhang2019-08-211-8/+14
| | | | PiperOrigin-RevId: 264612014
* 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-203-165/+364
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix parsing/printing of spv.globalVariable and spv._address_ofMahesh Ravishankar2019-08-191-20/+16
| | | | | | | | | | | | 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
* NFC: Move LLVMIR, SDBM, and StandardOps to the Dialect/ directory.River Riddle2019-08-191-1/+1
| | | | PiperOrigin-RevId: 264193915
* [spirv] Add spv.ReturnValueLei Zhang2019-08-191-4/+38
| | | | | | | | | 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-173-104/+473
| | | | | | | | | | | | | | | | | | | | 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-164-20/+107
| | | | | | | | 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-153-7/+50
| | | | | | | | | | 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
* Build SymbolTable upfront in ModuleOp verification.Mahesh Ravishankar2019-08-081-1/+2
| | | | | | | | Building the symbol table upfront from module op allows for O(1) lookup of the function while verifying duplicate EntryPointOp within the module. PiperOrigin-RevId: 262435697
* Add SymbolTable trait to spirv::ModuleOp.Mahesh Ravishankar2019-08-081-9/+4
| | | | | | | | Adding the SymbolTable trait allows looking up the name of the functions using the symbol table while verifying EntryPointOps instead of manually tracking the function names. PiperOrigin-RevId: 262431220
* 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
* Use SingleBlockImplicitTerminator trait for spv.moduleLei Zhang2019-08-051-8/+4
| | | | | | | | 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-013-86/+144
| | | | | | | | 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-011-0/+23
| | | | | | | | | | | 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
* Add support for (de)serialization of SPIR-V Op DecorationsMahesh Ravishankar2019-07-303-14/+104
| | | | | | | | | | | | 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-20/+51
| | | | | | | | | | | | | | | 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 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
OpenPOWER on IntegriCloud