summaryrefslogtreecommitdiffstats
path: root/mlir/lib/TableGen
Commit message (Collapse)AuthorAgeFilesLines
...
* NFC: Add a missing include for std::isalnum and std::digit.River Riddle2019-06-011-0/+1
| | | | | | -- PiperOrigin-RevId: 250085298
* Add support to RewritePattern for specifying the potential operations ↵River Riddle2019-06-011-0/+4
| | | | | | | | that can be generated during a rewrite. This will enable analyses to start understanding the possible effects of applying a rewrite pattern. -- PiperOrigin-RevId: 249936309
* Add pattern file location to generated code to trace origin of pattern.Jacques Pienaar2019-06-011-0/+14
| | | | | | -- PiperOrigin-RevId: 249734666
* [ODS] Allow dialect to specify C++ namespacesLei Zhang2019-05-203-21/+63
| | | | | | | | | | | Previously we force the C++ namespaces to be `NS` if `SomeOp` is defined as `NS_SomeOp`. This is too rigid as it does not support nested namespaces well. This CL adds a "namespace" field into the Dialect class to allow flexible namespaces. -- PiperOrigin-RevId: 249064981
* Remove unnecessary C++ specifier in CPP files. NFC.Jacques Pienaar2019-05-203-3/+3
| | | | | | | | These are only required in .h files to disambiguate between C and C++ header files. -- PiperOrigin-RevId: 248219135
* [TableGen] Return base attribute's name for anonymous ↵Lei Zhang2019-05-101-1/+3
| | | | | | | | OptionalAttr/DefaultValuedAttr -- PiperOrigin-RevId: 247693280
* Remove extra `;` after function definition (NFC)Mehdi Amini2019-05-101-1/+1
| | | | | | | | Fix a GCC warning -- PiperOrigin-RevId: 247670176
* Fix up some mixed sign warnings.Jacques Pienaar2019-05-061-6/+6
| | | | | | -- PiperOrigin-RevId: 246614498
* Add extraClassDeclaration field for ops.Jacques Pienaar2019-05-061-0/+7
| | | | | | | | Simple mechanism to allow specifying arbitrary function declarations. The modelling will not cover all cases so allow a means for users to declare a method function that they will define in their C++ files. The goal is to allow full C++ flexibility as the goal is to cover cases not modelled. -- PiperOrigin-RevId: 245889819
* Add Dialect in op definition to capture prefix and documentation.Jacques Pienaar2019-05-062-2/+8
| | | | | | | | | | | | Enables specifying the documentation for dialect along with defining the ops of the dialect. The doc generator will be expanded in follow up to emit the documentation in the autogenerated files. This is precursor to allowing common base for all ops in a dialect. All the dialect documentation is super sparse and just added as placeholder. I was tempted (and started) to move ConstantOp to be generated too, but this will be easier post adding extra_methods, so deferring until then. -- PiperOrigin-RevId: 245759984
* [TableGen] Support multiple variadic operands/resultsLei Zhang2019-05-062-18/+12
| | | | | | | | | | | | | | | | Certain ops can have multiple variadic operands/results, e.g., `tf.DynamicStitch`. Even if an op has only one variadic operand/result, it is not necessarily the very last one, e.g., `tf.RaggedGather`. This CL enhances TableGen subsystem to be able to represent such cases. In order to deduce the operand/result value range for each variadic operand, currently we only support variadic operands/results all of the same size. So two new traits, `SameVariadicOperandSize` and `SameVariadicResultSize` are introduced. -- PiperOrigin-RevId: 245310628
* [TableGen] Refine OpTrait classes and defs to be consistentLei Zhang2019-05-061-3/+3
| | | | | | -- PiperOrigin-RevId: 245075421
* [TableGen] Unify cOp and tAttr into NativeCodeCallLei Zhang2019-04-231-28/+12
| | | | | | | | | Both cOp and tAttr were used to perform some native C++ code expression. Unifying them simplifies the concepts and reduces cognitive burden. -- PiperOrigin-RevId: 244731946
* [TableGen] Capture bound source ops in PatternStateLei Zhang2019-04-231-14/+6
| | | | | | | | | | | | This allows accessing those bound source ops in result patterns, which can be useful for invoking native C++ op creation. We bind the op entirely here because ops can have multiple results. Design a approach to bind to a specific result is not the concern of this commit. -- PiperOrigin-RevId: 244724750
* [TableGen] Fix support for ops whose names have a leading underscoreLei Zhang2019-04-181-12/+20
| | | | | | | | | TensorFlow ops have the convention to use leading underscore to denote internal ops. -- PiperOrigin-RevId: 243627723
* NFC: Simplify named attribute in TableGen generatorsSmit Hinsu2019-04-181-9/+0
| | | | | | | | | | | Now, op attribute names don't have '.' in their names so the special handling for it can be removed. Attributes for functions still have dialect prefix with '.' as separator but TableGen does not deal with functions. TESTED with existing unit tests -- PiperOrigin-RevId: 243287462
* [TableGen] Allocate `Operator` object on heap in `RecordOperatorMap`Lei Zhang2019-04-181-1/+5
| | | | | | | | | | | | | | | | Iterators for a `llvm::DenseMap` can be invalidated when an insertion occurs. In Pattern's `collectBoundArguments()`, we recursively handle all nested DAG nodes and grow the the `RecordOperatorMap`, while retaining a reference. This can cause the reference to be invalid and the program to behave randomly. Allocate each `Operator` object specifically to solve this issue. Also, `llvm::DenseMap` is a great way to map pointers to pointers, or map other small types to each other. This avoids placing the `Operator` object directly into the map. -- PiperOrigin-RevId: 243281486
* [TableGen] Use `tgfmt` to format various predicates and rewrite rulesLei Zhang2019-04-181-25/+20
| | | | | | | | | | This CL changes various predicates and rewrite rules to use $-placeholders and `tgfmt` as the driver for substitution. This will make the predicates and rewrite rules more consistent regarding their arguments and more readable. -- PiperOrigin-RevId: 243250739
* [TableGen] Better support for predicate and rewrite rule specificationLei Zhang2019-04-182-0/+185
| | | | | | | | | | | | | | | | | | | | Currently predicates are written with positional placeholders `{N}` and rely on `formatv` as the engine to do substitution. The problem with this approach is that the definitions of those positional placeholders are not consistent; they are entirely up to the defining predicate of question. For example, `{0}` in various attribute constraints is used to mean the attribute, while it is used to main the builder for certain attribute transformations. This can become very confusing. This CL introduces `tgfmt` as a new mechanism to better support for predicate and rewrite rule specification. Instead of entirely relying on positional placeholders, `tgfmt` support both positional and special placeholders. The former is used for DAG operands. The latter, including $_builder, $_op, $_self, are used as special "hooks" to entities in the context. With this, the predicate and rewrite rules specification can be more consistent is more readable. -- PiperOrigin-RevId: 243249671
* [TableGen] Make sure op in pattern has the same number of arguments as ↵Lei Zhang2019-04-081-31/+33
| | | | | | | | | | | | definition When an op in the source pattern specifies more arguments than its definition, we will have out-of-bound query for op arguments from the definition. That will cause crashes. This change fixes it. -- PiperOrigin-RevId: 242548415
* Add methods for building array attributes in BuilderLei Zhang2019-04-071-2/+8
| | | | | | | | | I32/I64/F32/F64/Str array attributes are commonly used in ops. It helps to have handy methods for them. -- PiperOrigin-RevId: 242170569
* [TableGen] Support array attribute subclasses and constraintsLei Zhang2019-04-051-1/+26
| | | | | | | | | | To support automatically constraint composition of ArrayAttr, a new predicate combiner, Concat, is introduced. It prepends a prefix and appends a postfix to a child predicate's final predicate string. -- PiperOrigin-RevId: 242121186
* [TableGen] Rework verifier generation and error messagesLei Zhang2019-04-051-0/+6
| | | | | | | | | | | | | | | | | | | Previously we bundle the existence check and the MLIR attribute kind check in one call. Further constraints (like element bitwidth) have to be split into following checks. That is not a nice separation given that we have more checks for constraints. Instead, this CL changes to generate a local variable for every attribute, check its existence first, then check the constraints. Creating a local variable for each attribute also avoids querying it multiple times using the raw getAttr() API. This is a win for both performance the readability of the generated code. This CL also changed the error message to be more greppable by delimiting the error message from constraints with boilerplate part with colon. -- PiperOrigin-RevId: 241906132
* Minor fixes on the typo/naming/style in the Pattern.cpp fileFeng Liu2019-04-011-5/+7
| | | | | | -- PiperOrigin-RevId: 241341334
* [TableGen] Add EnumAttrCase and EnumAttrLei Zhang2019-04-012-13/+55
| | | | | | | | | | This CL adds EnumAttr as a general mechanism for modelling enum attributes. Right now it is using StringAttr under the hood since MLIR does not have native support for enum attributes. -- PiperOrigin-RevId: 241334043
* Add build files and update README.Jacques Pienaar2019-03-301-0/+14
| | | | | | | | | * Add initial version of build files; * Update README with instructions to download and build MLIR from github; -- PiperOrigin-RevId: 241102092
* remove the const quantifier before temp variableFeng Liu2019-03-291-1/+1
| | | | PiperOrigin-RevId: 240997262
* [TableGen] Support benefit score in pattern definition.Feng Liu2019-03-291-0/+10
| | | | | | | | A integer number can be specified in the pattern definition and used as the adjustment to the default benefit score in the generated rewrite pattern C++ definition. PiperOrigin-RevId: 240994192
* Add a trait to set the result type by attributeFeng Liu2019-03-293-1/+15
| | | | | | | | | Before this CL, the result type of the pattern match results need to be as same as the first operand type, operand broadcast type or a generic tensor type. This CL adds a new trait to set the result type by attribute. For example, the TFL_ConstOp can use this to set the output type to its value attribute. PiperOrigin-RevId: 240441249
* [TableGen] Consolidate constraint related conceptsLei Zhang2019-03-296-130/+104
| | | | | | | | | | | | | | | | | | | Previously we have multiple mechanisms to specify op definition and match constraints: TypeConstraint, AttributeConstraint, Type, Attr, mAttr, mAttrAnyOf, mPat. These variants are not added because there are so many distinct cases we need to model; essentially, they are all carrying a predicate. It's just an artifact of implementation. It's quite confusing for users to grasp these variants and choose among them. Instead, as the OpBase TableGen file, we need to strike to provide an unified mechanism. Each dialect has the flexibility to define its own aliases if wanted. This CL removes mAttr, mAttrAnyOf, mPat. A new base class, Constraint, is added. Now TypeConstraint and AttrConstraint derive from Constraint. Type and Attr further derive from TypeConstraint and AttrConstraint, respectively. Comments are revised and examples are added to make it clear how to use constraints. PiperOrigin-RevId: 240125076
* Change Value to NamedTypeConstraint and use TypeConstraint.Jacques Pienaar2019-03-293-14/+18
| | | | | | Previously Value was a pair of name & Type, but for operands/result a TypeConstraint rather then a Type is specified. Update C++ side to match declarative side. PiperOrigin-RevId: 238984799
* [TableGen] Support nested dag attributes arguments in the result patternFeng Liu2019-03-291-1/+16
| | | | | | | | | | Add support to create a new attribute from multiple attributes. It extended the DagNode class to represent attribute creation dag. It also changed the RewriterGen::emitOpCreate method to support this nested dag emit. An unit test is added. PiperOrigin-RevId: 238090229
* [TableGen] Support multiple result patternsLei Zhang2019-03-291-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | This CL added the ability to generate multiple ops using multiple result patterns, with each of them replacing one result of the matched source op. Specifically, the syntax is ``` def : Pattern<(SourceOp ...), [(ResultOp1 ...), (ResultOp2 ...), (ResultOp3 ...)]>; ``` Assuming `SourceOp` has three results. Currently we require that each result op must generate one result, which can be lifted later when use cases arise. To help with cases that certain output is unused and we don't care about it, this CL also introduces a new directive: `verifyUnusedValue`. Checks will be emitted in the `match()` method to make sure if the corresponding output is not unused, `match()` returns with `matchFailure()`. PiperOrigin-RevId: 237513904
* TableGen: allow mixing attributes and operands in the Arguments DAG of Op ↵Alex Zinenko2019-03-291-28/+21
| | | | | | | | | | | | | | | | | | | definition The existing implementation of the Op definition generator assumes and relies on the fact that native Op Attributes appear after its value-based operands in the Arguments list. Furthermore, the same order is used in the generated `build` function for the operation. This is not desirable for some operations with mandatory attributes that would want the attribute to appear upfront for better consistency with their textual representation, for example `cmpi` would prefer the `predicate` attribute to be foremost in the argument list. Introduce support for using attributes and operands in the Arguments DAG in no particular order. This is achieved by maintaining a list of Arguments that point to either the value or the attribute and are used to generate the `build` method. PiperOrigin-RevId: 237002921
* Change the TensorFlow attribute prefix from "tf$" to "tf." to match the ↵River Riddle2019-03-291-1/+1
| | | | | | specification of dialect attributes. This also fixes tblgen generation of dialect attributes that used the sugared name "tf$attr" as c++ identifiers. PiperOrigin-RevId: 236924392
* [TableGen] Use ArrayRef instead of SmallVectorImpl for suitable methodLei Zhang2019-03-291-1/+1
| | | | PiperOrigin-RevId: 235577399
* [TableGen] Fix infinite loop in SubstLeaves substitutionLei Zhang2019-03-291-4/+7
| | | | | | | | | | | Previously we have `auto pos = std::string::find(...) != std::string::npos` as if condition to control substring substitution. Instead of the position for the found substring, `pos` will be a boolean value indicating found nor not. Then used as the replace start position, we were always replacing starting from 0 or 1. If the replaced substring also has the pattern to be matched, we'll see an infinite loop. PiperOrigin-RevId: 235504681
* Spike to define real math ops and lowering of one variant of add to ↵Stella Laurenzo2019-03-291-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | corresponding integer ops. The only reason in starting with a fixedpoint add is that it is the absolute simplest variant and illustrates the level of abstraction I'm aiming for. The overall flow would be: 1. Determine quantization parameters (out of scope of this cl). 2. Source dialect rules to lower supported math ops to the quantization dialect (out of scope of this cl). 3. Quantization passes: [-quant-convert-const, -quant-lower-uniform-real-math, -quant-lower-unsupported-to-float] (the last one not implemented yet) 4. Target specific lowering of the integral arithmetic ops (roughly at the level of gemmlowp) to more fundamental operations (i.e. calls to gemmlowp, simd instructions, DSP instructions, etc). How I'm doing this should facilitate implementation of just about any kind of backend except TFLite, which has a very course, adhoc surface area for its quantized kernels. Options there include (I'm not taking an opinion on this - just trying to provide options): a) Not using any of this: just match q/dbarrier + tf math ops to the supported TFLite quantized op set. b) Implement the more fundamental integer math ops on TFLite and convert to those instead of the current op set. Note that I've hand-waved over the process of choosing appropriate quantization parameters. Getting to that next. As you can see, different implementations will likely have different magic combinations of specific math support, and we will need the target system that has been discussed for some of the esoteric cases (i.e. many DSPs only support POT fixedpoint). Two unrelated changes to the overall goal of this CL and can be broken out of desired: - Adding optional attribute support to TabelGen - Allowing TableGen native rewrite hooks to return nullptr, signalling that no rewrite has been done. PiperOrigin-RevId: 235267229
* Create OpTrait base class & allow operation predicate OpTraits.Jacques Pienaar2019-03-292-5/+81
| | | | | | | | | | | | * Introduce a OpTrait class in C++ to wrap the TableGen definition; * Introduce PredOpTrait and rename previous usage of OpTrait to NativeOpTrait; * PredOpTrait allows specifying a trait of the operation by way of predicate on the operation. This will be used in future to create reusable set of trait building blocks in the definition of operations. E.g., indicating whether to operands have the same type and allowing locally documenting op requirements by trait composition. - Some of these building blocks could later evolve into known fixed set as LLVMs backends do, but that can be considered with more data. * Use the modelling to address one verify TODO in a very local manner. This subsumes the current custom verify specification which will be removed in a separate mechanical CL. PiperOrigin-RevId: 234827169
* [TableGen] Support using Variadic<Type> in resultsLei Zhang2019-03-291-7/+34
| | | | | | | | | | This CL extended TableGen Operator class to provide accessors for information on op results. In OpDefinitionGen, added checks to make sure only the last result can be variadic, and adjusted traits and builders generation to consider variadic results. PiperOrigin-RevId: 234596124
* [TableGen] Rename Operand to Value to prepare sharing between operand and resultLei Zhang2019-03-292-2/+2
| | | | | | | We specify op operands and results in TableGen op definition using the same syntax. They should be modelled similarly in TableGen driver wrapper classes. PiperOrigin-RevId: 234153332
* [TableGen] Use deduced result types for build() of suitable opsLei Zhang2019-03-291-0/+7
| | | | | | | | | | | | | For ops with the SameOperandsAndResultType trait, we know that all result types should be the same as the first operand's type. So we can generate a build() method without requiring result types as parameters and also invoke this method when constructing such ops during expanding rewrite patterns. Similarly for ops have broadcast behavior, we can define build() method to use the deduced type as the result type. So we can also calling into this build() method when constructing ops in RewriterGen. PiperOrigin-RevId: 233988307
* Add pattern constraints.Jacques Pienaar2019-03-291-3/+81
| | | | | | Enable matching pattern only if constraint is met. Start with type constraints and more general C++ constraints. PiperOrigin-RevId: 233830768
* [TableGen] Assign created ops to variables and rewrite with ↵Lei Zhang2019-03-291-1/+5
| | | | | | | | | | | | | PatternRewriter::replaceOp() Previously we were using PatternRewrite::replaceOpWithNewOp() to both create the new op inline and rewrite the matched op. That does not work well if we want to generate multiple ops in a sequence. To support that, this CL changed to assign each newly created op to a separate variable. This CL also refactors how PatternEmitter performs the directive dispatch logic. PiperOrigin-RevId: 233206819
* [TableGen] Model variadic operands using Variadic<Type>Lei Zhang2019-03-292-0/+17
| | | | | | | | | | Previously, we were using the trait mechanism to specify that an op has variadic operands. That led a discrepancy between how we handle ops with deterministic number of operands. Besides, we have no way to specify the constraints and match against the variadic operands. This CL introduced Variadic<Type> as a way to solve the above issues. PiperOrigin-RevId: 232656104
* Add derived type attributes for TensorFlow ops generated by TableGenSmit Hinsu2019-03-291-3/+13
| | | | | | | | | | | | | | | Motivation for this change is to remove redundant TF type attributes for TensorFlow ops. For example, tf$T: "tfdtype$DT_FLOAT". Type attributes can be derived using the MLIR operand or result MLIR types, attribute names and their mapping. This will also allow constant folding of instructions generated within MLIR (and not imported from TensorFlow) without adding type attributes for the instruction. Derived attributes are populated while exporting MLIR to TF GraphDef using auto-generated populators. Populators are only available for the ops that are generated by the TableGen. Also, fixed Operator::getNumArgs method to exclude derived attributes as they are not part of the arguments. TESTED with unit test PiperOrigin-RevId: 232531561
* [TableGen] Use tblgen::DagLeaf to model DAG argumentsLei Zhang2019-03-292-6/+80
| | | | | | | | | | This CL added a tblgen::DagLeaf wrapper class with several helper methods for handling DAG arguments. It helps to refactor the rewriter generation logic to be more higher level. This CL also added a tblgen::ConstantAttr wrapper class for constant attributes. PiperOrigin-RevId: 232050683
* Add fallback to native code op builder specification for patterns.Jacques Pienaar2019-03-291-0/+11
| | | | | | | | This allow for arbitrarily complex builder patterns which is meant to cover initial cases while the modelling is improved and long tail cases/cases for which expanding the DSL would result in worst overall system. NFC just sorting the emit replace methods alphabetical in the class and file body. PiperOrigin-RevId: 231890352
* [tablegen] Use tblgen:: classes for NamedAttribute and Operand fieldsLei Zhang2019-03-293-21/+17
| | | | | | This is another step towards hiding raw TableGen API calls. PiperOrigin-RevId: 231580827
* [doc] Generate more readable description for attributesLei Zhang2019-03-291-0/+7
| | | | | | | This CL added "description" field to AttrConstraint and Attr, like what we have for type classes. PiperOrigin-RevId: 231579853
OpenPOWER on IntegriCloud