summaryrefslogtreecommitdiffstats
path: root/mlir/tools/mlir-tblgen
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix typos, NFC.Christian Sigg2019-10-043-4/+4
| | | | PiperOrigin-RevId: 272851237
* Fold away reduction over 0 dimensions.MLIR Team2019-09-301-1/+2
| | | | PiperOrigin-RevId: 272113564
* Enable autogenerating OpInterface method declarationsJacques Pienaar2019-09-302-102/+48
| | | | | | | | | | Add DeclareOpInterfaceFunctions to enable specifying whether OpInterfaceMethods for an OpInterface should be generated automatically. This avoids needing to declare the extra methods, while also allowing adding function declaration by way of trait/inheritance. Most of this change is mechanical/extracting classes to be reusable. PiperOrigin-RevId: 272042739
* Make result ops generated output deterministicJacques Pienaar2019-09-261-1/+7
| | | | | | Sort the result ops reported in lexographical order. PiperOrigin-RevId: 271426258
* Remove unused variables and methods to address compiler warningsLei Zhang2019-09-251-1/+1
| | | | PiperOrigin-RevId: 271256784
* Miscellaneous fixes to SPIR-V Deserializer (details below).Mahesh Ravishankar2019-09-241-4/+12
| | | | | | | | | | | | | | | 1) Process and ignore the following debug instructions: OpSource, OpSourceContinued, OpSourceExtension, OpString, OpModuleProcessed. 2) While processing OpTypeInt instruction, ignore the signedness specification. Currently MLIR doesnt make a distinction between signed and unsigned integer types. 3) Process and ignore BufferBlock decoration (similar to Buffer decoration). StructType needs to be enhanced to track this attribute since its needed for proper validation checks. 4) Report better error for unhandled instruction during deserialization. PiperOrigin-RevId: 271057060
* Allow attaching descriptions to OpInterfaces and InterfaceMethods.River Riddle2019-09-243-9/+156
| | | | | | | | | | | | | | | | | | | This change adds support for documenting interfaces and their methods. A tablegen generator for the interface documentation is also added(gen-op-interface-doc). Documentation is added to an OpInterface via the `description` field: def MyOpInterface : OpInterface<"MyOpInterface"> { let description = [{ My interface is very interesting. }]; } Documentation is added to an InterfaceMethod via a new `description` field that comes right before the optional body: InterfaceMethod<"void", "foo", (ins), [{ This is the foo method. }]>, PiperOrigin-RevId: 270965485
* [spirv] Add OpControlBarrier and OpMemoryBarrier.Denis Khalikov2019-09-211-0/+6
| | | | | | | | | 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-1/+1
| | | | | | 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-14/+14
| | | | | | 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-1/+1
| | | | | | MLIR follows the LLVM style of pass-by-reference. PiperOrigin-RevId: 270315612
* NFC: Fix return indentation in generated op definitions.Prakalp Srivastava2019-09-191-8/+8
| | | | PiperOrigin-RevId: 270070670
* Autogenerate (de)serialization for Extended Instruction SetsMahesh Ravishankar2019-09-161-197/+436
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 BitEnumAttrLei Zhang2019-09-163-8/+251
| | | | | | | | | | | | | | | | | | | | 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
* Improve verifier error reporting on type mismatch (NFC)MLIR Team2019-09-131-1/+1
| | | | | | | Before this change, it only reports expected type but not exact type, so it's hard to troubleshoot. PiperOrigin-RevId: 268961078
* Added a TableGen generator for structured dataRob Suderman2019-08-302-0/+260
| | | | | | Similar to enum, added a generator for structured data. This provide Dictionary that stores a fixed set of values and guarantees the values are valid. It is intended to store a fixed number of values by a given name. PiperOrigin-RevId: 266437460
* NFC: Avoid reconstructing the OpInterface methods.River Riddle2019-08-221-16/+8
| | | | PiperOrigin-RevId: 264881293
* Add support for generating operation interfaces from the ODS framework.River Riddle2019-08-212-0/+258
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Operation interfaces generally require a bit of boilerplate code to connect all of the pieces together. This cl introduces mechanisms in the ODS to allow for generating operation interfaces via the 'OpInterface' class. Providing a definition of the `OpInterface` class will auto-generate the c++ classes for the interface. An `OpInterface` includes a name, for the c++ class, along with a list of interface methods. There are two types of methods that can be used with an interface, `InterfaceMethod` and `StaticInterfaceMethod`. They are both comprised of the same core components, with the distinction that `StaticInterfaceMethod` models a static method on the derived operation. An `InterfaceMethod` is comprised of the following components: * ReturnType - A string corresponding to the c++ return type of the method. * MethodName - A string corresponding to the desired name of the method. * Arguments - A dag of strings that correspond to a c++ type and variable name respectively. * MethodBody (Optional) - An optional explicit implementation of the interface method. def MyInterface : OpInterface<"MyInterface"> { let methods = [ // A simple non-static method with no inputs. InterfaceMethod<"unsigned", "foo">, // A new non-static method accepting an input argument. InterfaceMethod<"Value *", "bar", (ins "unsigned":$i)>, // Query a static property of the derived operation. StaticInterfaceMethod<"unsigned", "fooStatic">, // Provide the definition of a static interface method. // Note: `ConcreteOp` corresponds to the derived operation typename. StaticInterfaceMethod<"Operation *", "create", (ins "OpBuilder &":$builder, "Location":$loc), [{ return builder.create<ConcreteOp>(loc); }]>, // Provide a definition of the non-static method. // Note: `op` corresponds to the derived operation variable. InterfaceMethod<"unsigned", "getNumInputsAndOutputs", (ins), [{ return op.getNumInputs() + op.getNumOutputs(); }]>, ]; PiperOrigin-RevId: 264754898
* Support variadic ops in declarative rewrite rulesLei Zhang2019-08-212-107/+208
| | | | | | | | | | | | | | | | | | | | | | | | This CL extends declarative rewrite rules to support matching and generating ops with variadic operands/results. For this, the generated `matchAndRewrite()` method for each pattern now are changed to * Use "range" types for the local variables used to store captured values (`operand_range` for operands, `ArrayRef<Value *>` for values, *Op for results). This allows us to have a unified way of handling both single values and value ranges. * Create local variables for each operand for op creation. If the operand is variadic, then a `SmallVector<Value*>` will be created to collect all values for that operand; otherwise a `Value*` will be created. * Use a collective result type builder. All result types are specified via a single parameter to the builder. We can use one result pattern to replace multiple results of the matched root op. When that happens, it will require specifying types for multiple results. Add a new collective-type builder. PiperOrigin-RevId: 264588559
* NFC: Don't assume that all operation traits are within the 'OpTrait::' ↵River Riddle2019-08-192-21/+23
| | | | | | | | namespace. This places an unnecessary restriction that all traits are within this namespace. PiperOrigin-RevId: 264212000
* InitLLVM already initializes PrettyStackTraceProgramJacques Pienaar2019-08-181-4/+2
| | | | | | Remove extra PrettyStackTraceProgram and use InitLLVM consistently. PiperOrigin-RevId: 264041205
* Allow the use of the $cppClass template variable in verifier code blocks.Ben Vanik2019-08-141-3/+7
| | | | PiperOrigin-RevId: 263378198
* NFC: Refactoring PatternSymbolResolver into SymbolInfoMapLei Zhang2019-08-091-247/+91
| | | | | | | | | | | | | | | In declarative rewrite rules, a symbol can be bound to op arguments or results in the source pattern, and it can be bound to op results in the result pattern. This means given a symbol in the pattern, it can stands for different things: op operand, op attribute, single op result, op result pack. We need a better way to model this complexity so that we can handle according to the specific kind a symbol corresponds to. Created SymbolInfo class for maintaining the information regarding a symbol. Also created a companion SymbolInfoMap class for a map of such symbols, providing insertion and querying depending on use cases. PiperOrigin-RevId: 262675515
* Translation to LLVM IR: use LogicalResult instead of boolAlex Zinenko2019-08-091-1/+1
| | | | | | | | The translation code predates the introduction of LogicalResult and was relying on the obsolete LLVM convention of returning false on success. Change it to use MLIR's LogicalResult abstraction instead. NFC. PiperOrigin-RevId: 262589432
* Emit matchAndRewrite() for declarative rewrite rulesLei Zhang2019-08-061-115/+107
| | | | | | | | | Previously we are emitting separate match() and rewrite() methods, which requires conveying a match state struct in a unique_ptr across these two methods. Changing to emit matchAndRewrite() simplifies the picture. PiperOrigin-RevId: 261906804
* [spirv] Provide decorations in batch for op constructionLei Zhang2019-08-061-11/+10
| | | | | | | | | | Instead of setting the attributes for decorations one by one after constructing the op, this CL changes to attach all the attributes for decorations to the attribute vector for constructing the op. This should be simpler and more efficient. PiperOrigin-RevId: 261905578
* NFC: Implement OwningRewritePatternList as a class instead of a using directive.River Riddle2019-08-051-2/+1
| | | | | | This allows for proper forward declaration, as opposed to leaking the internal implementation via a using directive. This also allows for all pattern building to go through 'insert' methods on the OwningRewritePatternList, replacing uses of 'push_back' and 'RewriteListBuilder'. PiperOrigin-RevId: 261816316
* Replace the verifyUnusedValue directive with HasNoUseOf constraintLei Zhang2019-08-011-44/+9
| | | | | | | | | verifyUnusedValue is a bit strange given that it is specified in a result pattern but used to generate match statements. Now we are able to support multi-result ops better, we can retire it and replace it with a HasNoUseOf constraint. This reduces the number of mechanisms. PiperOrigin-RevId: 261166863
* Fix support for auxiliary ops in declarative rewrite rulesLei Zhang2019-07-311-48/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We allow to generate more ops than what are needed for replacing the matched root op. Only the last N static values generated are used as replacement; the others serve as auxiliary ops/values for building the replacement. With the introduction of multi-result op support, an op, if used as a whole, may be used to replace multiple static values of the matched root op. We need to consider this when calculating the result range an generated op is to replace. For example, we can have the following pattern: ```tblgen def : Pattern<(ThreeResultOp ...), [(OneResultOp ...), (OneResultOp ...), (OneResultOp ...)]>; // Two op to replace all three results def : Pattern<(ThreeResultOp ...), [(TwoResultOp ...), (OneResultOp ...)]>; // One op to replace all three results def : Pat<(ThreeResultOp ...), (ThreeResultOp ...)>; def : Pattern<(ThreeResultOp ...), [(AuxiliaryOp ...), (ThreeResultOp ...)]>; ``` PiperOrigin-RevId: 261017235
* NFC: refactor ODS builder generationLei Zhang2019-07-311-142/+184
| | | | | | | | | | | Previously we use one single method with lots of branches to generate multiple builders. This makes the method difficult to follow and modify. This CL splits the method into multiple dedicated ones, by extracting common logic into helper methods while leaving logic specific to each builder in their own methods. PiperOrigin-RevId: 261011082
* Use operand number during serialization to get the <id>s of the operandsMahesh Ravishankar2019-07-311-1/+1
| | | | | | | | | | | 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
* Add support for (de)serialization of SPIR-V Op DecorationsMahesh Ravishankar2019-07-301-32/+49
| | | | | | | | | | | | 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-0/+3
| | | | | | | | | | | | | | | 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
* RewriterGen: properly handle zero-result opsAlex Zinenko2019-07-301-3/+3
| | | | | | | | | RewriterGen was emitting invalid C++ code if the pattern required to create a zero-result operation due to the absence of a special case that would avoid generating a spurious comma. Handle this case. Also add rewriter tests for zero-argument operations. PiperOrigin-RevId: 260576998
* Enable (de)serialization support for spirv::AccessChainOpMahesh Ravishankar2019-07-301-11/+30
| | | | | | | | | | 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
* [mlir-tblgen] Emit forward declarations for all the classes before the ↵Mehdi Amini2019-07-301-0/+8
| | | | | | | | definitions This allows classes to refer to each other in the ODS file, for instance for traits. PiperOrigin-RevId: 260532419
* Support referencing a single value generated by a matched multi-result opLei Zhang2019-07-261-18/+22
| | | | | | | | It's quite common that we want to put further constraints on the matched multi-result op's specific results. This CL enables referencing symbols bound to source op with the `__N` syntax. PiperOrigin-RevId: 260122401
* [spirv] NFC: adjust `encode*` function signatures in SerializerLei Zhang2019-07-221-3/+3
| | | | | | | | | * 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-221-2/+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-201-1/+1
| | | | | | | | | 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
* Suppress compiler warnings regarding unused variablesLei Zhang2019-07-191-2/+2
| | | | | | | Not all ops have operands or results, so it ends up there may be no use of wordIndex or the generated op's results. PiperOrigin-RevId: 258984485
* Automatically generate (de)serialization methods for SPIR-V opsMahesh Ravishankar2019-07-191-22/+300
| | | | | | | | | | | | | | | | 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
* Add serialization and deserialization of FuncOps. To support this theMahesh Ravishankar2019-07-121-4/+7
| | | | | | | | | | | | following SPIRV Instructions serializaiton/deserialization are added as well OpFunction OpFunctionParameter OpFunctionEnd OpReturn PiperOrigin-RevId: 257869806
* Update the gen_spirv_dialect.py script to add opcodes from the SPIR-VMahesh Ravishankar2019-07-121-6/+10
| | | | | | | | JSON spec into the SPIRBase.td file. This is done incrementally to only import those opcodes that are needed, through use of the script define_opcode.sh added. PiperOrigin-RevId: 257517343
* NFC: Rename Function to FuncOp.River Riddle2019-07-101-1/+1
| | | | PiperOrigin-RevId: 257293379
* ODS: provide a flag to skip generation of default build methodsAlex Zinenko2019-07-051-0/+7
| | | | | | | | | | | | | | | | | | | Some operations need to override the default behavior of builders, in particular region-holding operations such as affine.for or tf.graph want to inject default terminators into the region upon construction, which default builders won't do. Provide a flag that disables the generation of default builders so that the custom builders could use the same function signatures. This is an intentionally low-level and heavy-weight feature that requires the entire builder to be implemented, and it should be used sparingly. Injecting code into the end of a default builder would depend on the naming scheme of the default builder arguments that is not visible in the ODS. Checking that the signature of a custom builder conflicts with that of a default builder to prevent emission would require teaching ODG to differentiate between types and (optional) argument names in the generated C++ code. If this flag ends up being used a lot, we should consider adding traits that inject specific code into the default builder. PiperOrigin-RevId: 256640069
* Add ODS accessors for named regions.Nicolas Vasilache2019-07-051-0/+15
| | | | PiperOrigin-RevId: 256639471
* NFC: Refactoring to remove code bloat in SPIRV due to handling of EnumMahesh Ravishankar2019-07-033-70/+143
| | | | | | Class Attribute parsing PiperOrigin-RevId: 256471248
* [TableGen] Support creating multi-result ops in result patternsLei Zhang2019-07-031-30/+93
| | | | | | | | | | This CL introduces a new syntax for creating multi-result ops and access their results in result patterns. Specifically, if a multi-result op is unbound or bound to a name without a trailing `__N` suffix, it will act as a value pack and expand to all its values. If a multi-result op is bound to a symbol with `__N` suffix, only the N-th result will be extracted and used. PiperOrigin-RevId: 256465208
* Also disable generating underlying value to symbol conversion declaration ↵Lei Zhang2019-07-011-3/+7
| | | | | | when there is an enumerant without explicit value PiperOrigin-RevId: 255950779
OpenPOWER on IntegriCloud