summaryrefslogtreecommitdiffstats
path: root/mlir/lib/TableGen
Commit message (Collapse)AuthorAgeFilesLines
* [mlir] NFC: put C++ code emission classes in their own filesLei Zhang2020-01-102-0/+236
| | | | | | This exposes thse classes so that they can be used in interfaces. Differential Revision: https://reviews.llvm.org/D72514
* [mlir][spirv] Allow specifying availability on enum attribute casesLei Zhang2020-01-021-0/+6
| | | | | | | | | | | | | | Lots of SPIR-V ops take enum attributes and certain enum cases need extra capabilities or extensions to be available. This commit extends to allow specifying availability spec on enum cases. Extra utility functions are generated for the corresponding enum classes to return the availability requirement. The availability interface implemention for a SPIR-V op now goes over all enum attributes to collect the availability requirements. Reviewed By: mravishankar Differential Revision: https://reviews.llvm.org/D71947
* NFC: Replace ValuePtr with Value and remove it now that Value is value-typed.River Riddle2019-12-231-1/+1
| | | | | | ValuePtr was a temporary typedef during the transition to a value-typed Value. PiperOrigin-RevId: 286945714
* Adjust License.txt file to use the LLVM licenseMehdi Amini2019-12-2311-143/+44
| | | | PiperOrigin-RevId: 286906740
* NFC: Introduce new ValuePtr/ValueRef typedefs to simplify the transition to ↵River Riddle2019-12-221-1/+1
| | | | | | | | | | Value being value-typed. This is an initial step to refactoring the representation of OpResult as proposed in: https://groups.google.com/a/tensorflow.org/g/mlir/c/XXzzKhqqF_0/m/v6bKb08WCgAJ This change will make it much simpler to incrementally transition all of the existing code to use value-typed semantics. PiperOrigin-RevId: 286844725
* Unique trait list during ODS Operator trait constructionJacques Pienaar2019-12-191-6/+13
| | | | | | Concatting lists in TableGen is easy, creating unique lists less so. There is no reason for duplicated op traits so we could throw an error instead but duplicates could occur due to concatting different list of traits in ODS (e.g., for convenience reasons), so just dedup them during Operator trait construction instead. PiperOrigin-RevId: 286488423
* Add support for providing a default implementation for an interface method.River Riddle2019-12-181-0/+6
| | | | | | | | | | | | | | | | | | | | This enables providing a default implementation of an interface method. This method is defined on the Trait that is attached to the operation, and thus has all of the same constraints and properties as any other interface method. This allows for interface authors to provide a conservative default implementation for certain methods, without requiring that all users explicitly define it. The default implementation can be specified via the argument directly after the interface method body: StaticInterfaceMethod< /*desc=*/"Returns whether two array of types are compatible result types for an op.", /*retTy=*/"bool", /*methodName=*/"isCompatibleReturnTypes", /*args=*/(ins "ArrayRef<Type>":$lhs, "ArrayRef<Type>":$rhs), /*methodBody=*/[{ return ConcreteOp::isCompatibleReturnTypes(lhs, rhs); }], /*defaultImplementation=*/[{ /// Returns whether two arrays are equal as strongest check for /// compatibility by default. return lhs == rhs; }] PiperOrigin-RevId: 286226054
* [ODS] Generate builders taking unwrapped value and defaults for attributesLei Zhang2019-12-021-2/+2
| | | | | | | | | | | | | | | | | | Existing builders generated by ODS require attributes to be passed in as mlir::Attribute or its subclasses. This is okay foraggregate- parameter builders, which is primarily to be used by programmatic C++ code generation; it is inconvenient for separate-parameter builders meant to be called in manually written C++ code because it requires developers to wrap raw values into mlir::Attribute by themselves. This CL extends to generate additional builder methods that take raw values for attributes and handles the wrapping in the builder implementation. Additionally, if an attribute appears late in the arguments list and has a default value, the default value is supplied in the declaration if possible. PiperOrigin-RevId: 283355919
* [DRR] Introduce `$_` to ignore op argument matchLei Zhang2019-12-021-1/+2
| | | | | | | | Right now op argument matching in DRR is position-based, meaning we need to specify N arguments for an op with N ODS-declared argument. This can be annoying when we don't want to capture all the arguments. `$_` is to remedy the situation. PiperOrigin-RevId: 283339992
* Add support for AttrSizedOperandSegments/AttrSizedResultSegmentsLei Zhang2019-11-251-6/+6
| | | | | | | | | | | | | | | | | Certain operations can have multiple variadic operands and their size relationship is not always known statically. For such cases, we need a per-op-instance specification to divide the operands into logical groups or segments. This can be modeled by attributes. This CL introduces C++ trait AttrSizedOperandSegments for operands and AttrSizedResultSegments for results. The C++ trait just guarantees such size attribute has the correct type (1D vector) and values (non-negative), etc. It serves as the basis for ODS sugaring that with ODS argument declarations we can further verify the number of elements match the number of ODS-declared operands and we can generate handy getter methods. PiperOrigin-RevId: 282467075
* Add support for using the ODS result names as the Asm result names for ↵River Riddle2019-11-211-0/+3
| | | | | | | | | | | | | | | multi-result operations. This changes changes the OpDefinitionsGen to automatically add the OpAsmOpInterface for operations with multiple result groups using the provided ODS names. We currently just limit the generation to multi-result ops as most single result operations don't have an interesting name(result/output/etc.). An example is shown below: // The following operation: def MyOp : ... { let results = (outs AnyType:$first, Variadic<AnyType>:$middle, AnyType); } // May now be printed as: %first, %middle:2, %0 = "my.op" ... PiperOrigin-RevId: 281834156
* [ODS] Fix operation argument population to avoid crashLei Zhang2019-11-142-6/+34
| | | | | | | | | | The `Operator` class keeps an `arguments` field, which contains pointers to `operands` and `attributes` elements. Thus it must be populated after `operands` and `attributes` are finalized so to have stable pointers. SmallVector may re-allocate when still having new elements added, which will invalidate pointers. PiperOrigin-RevId: 280466896
* Expose an isSubclassOf() method on AttrConstraintLei Zhang2019-11-121-11/+13
| | | | PiperOrigin-RevId: 280021408
* Move BitEnumAttr from SPIRVBase.td to OpBase.tdLei Zhang2019-11-011-2/+2
| | | | | | | | | | | | | | | | | BitEnumAttr is a mechanism for modelling attributes whose value is a bitfield. It should not be scoped to the SPIR-V dialect and can be used by other dialects too. This CL is mostly shuffling code around and adding tests and docs. Functionality changes are: * Fixed to use `getZExtValue()` instead of `getSExtValue()` when getting the value from the underlying IntegerAttr for a case. * Changed to auto-detect whether there is a case whose value is all bits unset (i.e., zero). If so handle it specially in all helper methods. PiperOrigin-RevId: 277964926
* Fix segfault when no symbol is given to an constraint operandLei Zhang2019-10-301-1/+7
| | | | | | | This fixed the segfault when we see the following pattern: Pat<(...), (...), [(... 1, 2, 3), ...]> PiperOrigin-RevId: 277544300
* [DRR] Allow interleaved operands and attributesLei Zhang2019-10-211-0/+12
| | | | | | | | Previously DRR assumes attributes to appear after operands. This was the previous requirements on ODS, but that has changed some time ago. Fix DRR to also support interleaved operands and attributes. PiperOrigin-RevId: 275983485
* Fix minor spelling tweaks (NFC)Kazuaki Ishizaki2019-10-202-3/+3
| | | | | | Closes tensorflow/mlir#177 PiperOrigin-RevId: 275692653
* [DRR] Allow capturing and referencing no-result opsLei Zhang2019-10-171-0/+7
| | | | | | | | | | Previously when we bind a symbol to an op in DRR, it means to capture the op's result(s) and later references will be expanded to result(s). This means for ops without result, we are replacing the symbol with nothing. This CL treats non-result op capturing and referencing as a special case to mean the op itself. PiperOrigin-RevId: 275269702
* Add LLVM_DEBUG in RewritersGen.cpp and Pattern.cppLei Zhang2019-10-171-10/+53
| | | | | | | | | It's usually hard to understand what went wrong if mlir-tblgen crashes on some input. This CL adds a few useful LLVM_DEBUG statements so that we can use mlir-tblegn -debug to figure out the culprit for a crash. PiperOrigin-RevId: 275253532
* Add DialectType and generate docs for dialect typesJacques Pienaar2019-10-072-8/+19
| | | | | | Add new `typeDescription` (description was already used by base constraint class) field to type to allow writing longer descriptions about a type being defined. This allows for providing additional information/rationale for a defined type. This currently uses `description` as the heading/name for the type in the generated documentation. PiperOrigin-RevId: 273299332
* Enable emitting dialect summary & description during op generationJacques Pienaar2019-10-051-0/+26
| | | | | | Sort ops per dialect and emit summary & description (if provided) of each dialect before emitting the ops of the dialect. PiperOrigin-RevId: 273077138
* Add missing file from cmakelistJacques Pienaar2019-09-301-0/+1
| | | | PiperOrigin-RevId: 272054623
* Enable autogenerating OpInterface method declarationsJacques Pienaar2019-09-302-7/+113
| | | | | | | | | | 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
* Remove unused variables and methods to address compiler warningsLei Zhang2019-09-251-0/+1
| | | | PiperOrigin-RevId: 271256784
* [spirv] Add support for BitEnumAttrLei Zhang2019-09-161-0/+8
| | | | | | | | | | | | | | | | | | | | 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
* Added a TableGen generator for structured dataRob Suderman2019-08-301-0/+52
| | | | | | 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
* Support variadic ops in declarative rewrite rulesLei Zhang2019-08-211-16/+87
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Change from llvm::make_unique to std::make_uniqueJacques Pienaar2019-08-171-1/+1
| | | | | | | | Switch to C++14 standard method as llvm::make_unique has been removed ( https://reviews.llvm.org/D66259). Also mark some targets as c++14 to ease next integrates. PiperOrigin-RevId: 263953918
* Add unreachable to avoid GCC -Wreturn-type warningjpienaar2019-08-131-0/+3
| | | | | | | | GCC warns of control reaching end of non-void function (-Wreturn-type). Closes tensorflow/mlir#75 PiperOrigin-RevId: 263214601
* NFC: Refactoring PatternSymbolResolver into SymbolInfoMapLei Zhang2019-08-091-35/+184
| | | | | | | | | | | | | | | 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
* Qualify StringRef to fix Windows build failureLei Zhang2019-08-011-1/+2
| | | | PiperOrigin-RevId: 261195069
* Replace the verifyUnusedValue directive with HasNoUseOf constraintLei Zhang2019-08-012-10/+5
| | | | | | | | | 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-14/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove dead code.Jacques Pienaar2019-07-303-58/+0
| | | | PiperOrigin-RevId: 260585594
* Support referencing a single value generated by a matched multi-result opLei Zhang2019-07-261-2/+3
| | | | | | | | 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
* Automatically generate (de)serialization methods for SPIR-V opsMahesh Ravishankar2019-07-192-1/+5
| | | | | | | | | | | | | | | | 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
* Better support for attribute wrapper classes when getting def nameLei Zhang2019-07-161-2/+11
| | | | | | | | | | | | | | | | | | | | | Unless we explicitly name a template instantiation in .td file, its def name will be "anonymous_<number>". We typically give base-level Attr template instantiation a name by writing `def AnAttr : Attr<...>`. But when `AnAttr` is further wrapped in classes like OptionalAttr, the name is lost unless explicitly def'ed again. These implicit-named template instantiation is fairly common when writing op definitions. Those wrapper classes are just essentially attaching more information to the attribute. Without a proper way to trace back to the original attribute def name can cause problems for consumers wanting to handle attributes according to their types. Previously we handled OptionalAttr and DefaultValuedAttr specifically, but Confined was not supported. And they can compose together to have Confined<OptionalAttr<...>, [...]>. So this CL moves the baseAttr field to main Attr class (like isOptional) and set it only on the innermost wrapper class. PiperOrigin-RevId: 258341646
* ODS: provide a flag to skip generation of default build methodsAlex Zinenko2019-07-051-0/+4
| | | | | | | | | | | | | | | | | | | 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
* [ODS] NFC: Rename EnumAttr to StrEnumAttr to be consistent with IntEnumAttrLei Zhang2019-07-021-2/+2
| | | | PiperOrigin-RevId: 256169019
* EnumsGen: remove dangling assertionLei Zhang2019-07-021-1/+0
| | | | | | | | | StringAttr-backed enum attribute cases changed to allow explicit values, But this assertion was not deleted. Fixes https://github.com/tensorflow/mlir/issues/39 PiperOrigin-RevId: 256090793
* [ODS] Introduce IntEnumAttrLei Zhang2019-07-012-4/+13
| | | | | | | | | | | | | | | | | | | In ODS, right now we use StringAttrs to emulate enum attributes. It is suboptimal if the op actually can and wants to store the enum as a single integer value; we are paying extra cost on storing and comparing the attribute value. This CL introduces a new enum attribute subclass that are backed by IntegerAttr. The downside with IntegerAttr-backed enum attributes is that the assembly form now uses integer values, which is less obvious than the StringAttr-backed ones. However, that can be remedied by defining custom assembly form with the help of the conversion utility functions generated via EnumsGen. Choices are given to the dialect writers to decide which one to use for their enum attributes. PiperOrigin-RevId: 255935542
* [spirv] Basic serializer and deserializerLei Zhang2019-06-221-0/+4
| | | | | | | | | | | | | | | | This CL adds the basic SPIR-V serializer and deserializer for converting SPIR-V module into the binary format and back. Right now only an empty module with addressing model and memory model is supported; (de)serialize other components will be added gradually with subsequent CLs. The purpose of this library is to enable importing SPIR-V binary modules to run transformations on them and exporting SPIR-V modules to be consumed by execution environments. The focus is transformations, which inevitably means changes to the binary module; so it is not designed to be a general tool for investigating the SPIR-V binary module and does not guarantee roundtrip equivalence (at least for now). PiperOrigin-RevId: 254473019
* Add SPIRV Image Type according to the spec described here :Mahesh Ravishankar2019-06-191-0/+4
| | | | | | | | | | | | | https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html#OpTypeImage. Add new enums to describe Image dimensionality, Image Depth, Arrayed information, Sampling, Sampler User information, and Image format. Doesn's support the Optional Access qualifier at this stage Fix Enum generator for tblgen to add "_" at the beginning if the enum starts with a number. PiperOrigin-RevId: 254091423
* Print proper message saying variadic ops are not supported in RewriterGenLei Zhang2019-06-191-0/+4
| | | | | | | | Support for ops with variadic operands/results will come later; but right now a proper message helps to avoid deciphering confusing error messages later in the compilation stage. PiperOrigin-RevId: 254071820
* [ODS] Support variadic operand/result verificationLei Zhang2019-06-091-2/+2
| | | | | | | | | This CL enables verification code generation for variadic operands and results. In verify(), we use fallback getter methods to access all the dynamic values belonging to one static variadic operand/result to reuse the value range calculation there. PiperOrigin-RevId: 252288219
* [TableGen] Generating enum definitions and utility functionsLei Zhang2019-06-091-0/+22
| | | | | | | | | | | | | Enum attributes can be defined using `EnumAttr`, which requires all its cases to be defined with `EnumAttrCase`. To facilitate the interaction between `EnumAttr`s and their C++ consumers, add a new EnumsGen TableGen backend to generate a few common utilities, including an enum class, `llvm::DenseMapInfo` for the enum class, conversion functions from/to strings. This is controlled via the `-gen-enum-decls` and `-gen-enum-defs` command-line options of `mlir-tblgen`. PiperOrigin-RevId: 252209623
* [ODG] Add iterators for results in OperatorLei Zhang2019-06-091-3/+13
| | | | PiperOrigin-RevId: 251417085
* Introduce OpOperandAdaptors and emit them from ODSAlex Zinenko2019-06-031-0/+2
| | | | | | | | | | | | | | | | | | | | | When manipulating generic operations, such as in dialect conversion / rewriting, it is often necessary to view a list of Values as operands to an operation without creating the operation itself. The absence of such view makes dialect conversion patterns, among others, to use magic numbers to obtain specific operands from a list of rewritten values when converting an operation. Introduce XOpOperandAdaptor classes that wrap an ArrayRef<Value *> and provide accessor functions identical to those available in XOp. This makes it possible for conversions to use these adaptors to address the operands with names rather than rely on their position in the list. The adaptors are generated from ODS together with the actual operation definitions. This is another step towards making dialect conversion patterns specific for a given operation. Illustrate the approach on conversion patterns in the standard to LLVM dialect conversion. PiperOrigin-RevId: 251232899
* [ODS] Support region names and constraintsLei Zhang2019-06-012-4/+35
| | | | | | | | | | | | | Similar to arguments and results, now we require region definition in ops to be specified as a DAG expression with the 'region' operator. This way we can specify the constraints for each region and optionally give the region a name. Two kinds of region constraints are added, one allowing any region, and the other requires a certain number of blocks. -- PiperOrigin-RevId: 250790211
* [ODS] Support numRegions in Op definitionLei Zhang2019-06-011-0/+7
| | | | | | -- PiperOrigin-RevId: 250282024
OpenPOWER on IntegriCloud