summaryrefslogtreecommitdiffstats
path: root/mlir/lib/Dialect/SPIRV/SPIRVOps.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [spirv] Add SPV_UnaryOp and spv.FNegateLei Zhang2019-09-251-57/+56
| | | | | | | This CL also moves common parsers and printers to the same section in SPIRVOps.cpp. PiperOrigin-RevId: 271233546
* [spirv] Replace bitwiseCast with llvm::bit_castLei Zhang2019-09-241-11/+3
| | | | PiperOrigin-RevId: 271035618
* [spirv] Add OpControlBarrier and OpMemoryBarrier.Denis Khalikov2019-09-211-11/+84
| | | | | | | | | 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-201-102/+100
| | | | | | 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
* 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
* Autogenerate (de)serialization for Extended Instruction SetsMahesh Ravishankar2019-09-161-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-161-0/+103
| | | | | | | | | 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-2/+2
| | | | | | | | | | | | | | | | | | | | 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
* [spirv] Add support for spv.loop (de)serializationLei Zhang2019-09-111-8/+33
| | | | | | | | 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-031-4/+24
| | | | | | | | | 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
* 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] 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-221-0/+10
| | | | | | | 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-221-0/+11
| | | | | | | 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
* Add spv.specConstant and spv._reference_ofLei Zhang2019-08-201-29/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
* [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-171-87/+260
| | | | | | | | | | | | | | | | | | | | 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
* Add BuiltIn EnumAttr to SPIR-V dialectMahesh Ravishankar2019-08-151-7/+30
| | | | | | | | | | 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
* 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
* 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-011-1/+6
| | | | | | | | 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-301-14/+30
| | | | | | | | | | | | 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-301-20/+18
| | | | | | | | | | | | | | | 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 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
* [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
* Make SPIR-V spv.EntryPoint and spv.ExecutionMode consistent with SPIR-V specMahesh Ravishankar2019-07-191-11/+5
| | | | | | | | | | | | | 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
* NFC: Move SPIR-V dialect to Dialect/ subdirectoryLei Zhang2019-07-161-0/+852
PiperOrigin-RevId: 258345603
OpenPOWER on IntegriCloud