summaryrefslogtreecommitdiffstats
path: root/mlir/tools
Commit message (Collapse)AuthorAgeFilesLines
...
* Create OpTrait base class & allow operation predicate OpTraits.Jacques Pienaar2019-03-291-3/+16
| | | | | | | | | | | | * 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
* NFC: Refactor the files related to passes.River Riddle2019-03-291-2/+1
| | | | | | | * PassRegistry is split into its own source file. * Pass related files are moved to a new library 'Pass'. PiperOrigin-RevId: 234705771
* [TableGen] Support using Variadic<Type> in resultsLei Zhang2019-03-291-19/+45
| | | | | | | | | | 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] Fix discrepancy between parameter meaning and code logicLei Zhang2019-03-292-14/+16
| | | | | | | | | | The parameter to emitStandaloneParamBuilder() was renamed from hasResultType to isAllSameType, which is the opposite boolean value. The logic should be changed to make them consistent. Also re-ordered some methods in Operator. And few other tiny improvements. PiperOrigin-RevId: 234478316
* ExecutionEngine: provide utils for running CLI-configured LLVM passesAlex Zinenko2019-03-291-3/+45
| | | | | | | | | | | | | | | | | | | A recent change introduced a possibility to run LLVM IR transformation during JIT-compilation in the ExecutionEngine. Provide helper functions that construct IR transformers given either clang-style optimization levels or a list passes to run. The latter wraps the LLVM command line option parser to parse strings rather than actual command line arguments. As a result, we can run either of mlir-cpu-runner -O3 input.mlir mlir-cpu-runner -some-mlir-pass -llvm-opts="-llvm-pass -other-llvm-pass" to combine different transformations. The transformer builder functions are provided as a separate library that depends on LLVM pass libraries unlike the main execution engine library. The library can be used for integrating MLIR execution engine into external frameworks. PiperOrigin-RevId: 234173493
* [TableGen] Rename Operand to Value to prepare sharing between operand and resultLei Zhang2019-03-292-4/+4
| | | | | | | 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
* [TFLite] Fuse AddOp into preceding convolution opsLei Zhang2019-03-291-5/+0
| | | | | | | | | | | If we see an add op adding a constant value to a convolution op with constant bias, we can fuse the add into the convolution op by constant folding the bias and the add op's constant operand. This CL also removes dangling RewriterGen check that prevents us from using nested DAG nodes in result patterns, which is already supported. PiperOrigin-RevId: 233989654
* [TableGen] Use deduced result types for build() of suitable opsLei Zhang2019-03-292-25/+63
| | | | | | | | | | | | | 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
* Reimplement LLVM IR translation to use the MLIR LLVM IR dialectAlex Zinenko2019-03-291-8/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
* Add pattern constraints.Jacques Pienaar2019-03-291-4/+52
| | | | | | Enable matching pattern only if constraint is met. Start with type constraints and more general C++ constraints. PiperOrigin-RevId: 233830768
* [TFLite] Add rewrite pattern to fuse conv ops with Relu6 opLei Zhang2019-03-291-12/+14
| | | | | | | | | * Fixed tfl.conv_2d and tfl.depthwise_conv_2d to have fused activation function attribute * Fixed RewriterGen crash: trying to get attribute match template when the matcher is unspecified (UnsetInit) PiperOrigin-RevId: 233241755
* [TableGen] Support nested DAG nodes in result result op argumentsLei Zhang2019-03-291-3/+40
| | | | | | | | | | This CL allowed developers to write result ops having nested DAG nodes as their arguments. Now we can write ``` def : Pat<(...), (AOp (BOp, ...), AOperand)> ``` PiperOrigin-RevId: 233207225
* [TableGen] Assign created ops to variables and rewrite with ↵Lei Zhang2019-03-291-39/+105
| | | | | | | | | | | | | 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
* Add tf.LeakyRelu.Jacques Pienaar2019-03-291-1/+1
| | | | | | | | | | | * Add tf.LeakyRelu op definition + folders (well one is really canonicalizer) * Change generated error message to use attribute description instead; * Change the return type of F32Attr to be APFloat - internally it is already stored as APFloat so let the caller decides if they want to convert it or not. I could see varying opinions here though :) (did not change i32attr similarly) PiperOrigin-RevId: 232923358
* [TableGen] Model variadic operands using Variadic<Type>Lei Zhang2019-03-291-32/+41
| | | | | | | | | | 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
* Begin the process of fully removing OperationInst. This patch cleans up ↵River Riddle2019-03-292-3/+3
| | | | | | references to OperationInst in the /include, /AffineOps, and lib/Analysis. PiperOrigin-RevId: 232199262
* Fold the functionality of OperationInst into Instruction. OperationInst ↵River Riddle2019-03-291-1/+1
| | | | | | still exists as a forward declaration and will be removed incrementally in a set of followup cleanup patches. PiperOrigin-RevId: 232198540
* Merge OpProperty and Traits into OpTraitLei Zhang2019-03-291-24/+11
| | | | | | | | | | | | | | | They are essentially both modelling MLIR OpTrait; the former achieves the purpose via introducing corresponding symbols in TableGen, while the latter just uses plain strings. Unify them to provide a single mechanism to avoid confusion and to better reflect the definitions on MLIR C++ side. Ideally we should be able to deduce lots of these traits automatically via other bits of op definitions instead of manually specifying them; but not for now though. PiperOrigin-RevId: 232191401
* [TableGen] Use tblgen::DagLeaf to model DAG argumentsLei Zhang2019-03-291-109/+123
| | | | | | | | | | 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
* Cleanup EDSCs and start a functional auto-generated library of custom OpsNicolas Vasilache2019-03-291-31/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL applies the following simplifications to EDSCs: 1. Rename Block to StmtList because an MLIR Block is a different, not yet supported, notion; 2. Rework Bindable to drop specific storage and just use it as a simple wrapper around Expr. The only value of Bindable is to force a static cast when used by the user to bind into the emitter. For all intended purposes, Bindable is just a lightweight check that an Expr is Unbound. This simplifies usage and reduces the API footprint. After playing with it for some time, it wasn't worth the API cognition overhead; 3. Replace makeExprs and makeBindables by makeNewExprs and copyExprs which is more explicit and less easy to misuse; 4. Add generally useful functionality to MLIREmitter: a. expose zero and one for the ubiquitous common lower bounds and step; b. add support to create already bound Exprs for all function arguments as well as shapes and views for Exprs bound to memrefs. 5. Delete Stmt::operator= and replace by a `Stmt::set` method which is more explicit. 6. Make Stmt::operator Expr() explicit. 7. Indexed.indices assertions are removed to pave the way for expressing slices and views as well as to work with 0-D memrefs. The CL plugs those simplifications with TableGen and allows emitting a full MLIR function for pointwise add. This "x.add" op is both type and rank-agnostic (by allowing ArrayRef of Expr passed to For loops) and opens the door to spinning up a composable library of existing and custom ops that should automate a lot of the tedious work in TF/XLA -> MLIR. Testing needs to be significantly improved but can be done in a separate CL. PiperOrigin-RevId: 231982325
* Add fallback to native code op builder specification for patterns.Jacques Pienaar2019-03-291-13/+42
| | | | | | | | 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
* Enable using constant attribute as matchers.Jacques Pienaar2019-03-291-0/+1
| | | | | | Straight roll-forward of cl/231322019 that got accidentally reverted in the move. PiperOrigin-RevId: 231791464
* [tablegen] Use tblgen:: classes for NamedAttribute and Operand fieldsLei Zhang2019-03-294-22/+18
| | | | | | This is another step towards hiding raw TableGen API calls. PiperOrigin-RevId: 231580827
* [doc] Use table to list all attributesLei Zhang2019-03-291-2/+7
| | | | | | For each attribute, list its MLIR type and description. PiperOrigin-RevId: 231580353
* [doc] Generate more readable description for attributesLei Zhang2019-03-291-6/+2
| | | | | | | This CL added "description" field to AttrConstraint and Attr, like what we have for type classes. PiperOrigin-RevId: 231579853
* [doc] Generate more readable description for operandsLei Zhang2019-03-291-4/+3
| | | | | | | | This CL mandated TypeConstraint and Type to provide descriptions and fixed various subclasses and definitions to provide so. The purpose is to enforce good documentation; using empty string as the default just invites oversight. PiperOrigin-RevId: 231579629
* Include op results in generate TensorFlow/TFLite op docsLei Zhang2019-03-291-10/+25
| | | | | | | | | | | * Emitted result lists for ops. * Changed to allow empty summary and description for ops. * Avoided indenting description to allow proper MarkDown rendering of formatting markers inside description content. * Used fixed width font for operand/attribute names. * Massaged TensorFlow op docs and generated dialect op doc. PiperOrigin-RevId: 231427574
* TableGen: Use DAG for op resultsLei Zhang2019-03-291-9/+10
| | | | | | | | | Similar to op operands and attributes, use DAG to specify operation's results. This will allow us to provide names and matchers for outputs. Also Defined `outs` as a marker to indicate the start of op result list. PiperOrigin-RevId: 231422455
* Prefix Operator getter methods with "get" to be consistentLei Zhang2019-03-293-6/+6
| | | | PiperOrigin-RevId: 231416230
* Move google-mlir to google_mlirNicolas Vasilache2019-03-291-1/+0
| | | | | | | Python modules cannot be defined under a directory that has a `-` character in its name inside of Google code. Rename to `google_mlir` which circumvents this limitation. PiperOrigin-RevId: 231329321
* Enable using constant attribute as matchers.Jacques Pienaar2019-03-291-0/+1
| | | | | | Update to allow constant attribute values to be used to match or as result in rewrite rule. Define variable ctx in the matcher to allow matchers to refer to the context of the operation being matched. PiperOrigin-RevId: 231322019
* Add tblgen::Pattern to model Patterns defined in TableGenLei Zhang2019-03-291-130/+95
| | | | | | | Similar to other tblgen:: abstractions, tblgen::Pattern hides the native TableGen API and provides a nicer API that is more coherent with the TableGen definitions. PiperOrigin-RevId: 231285143
* Define mAttr in terms of AttrConstraint.Jacques Pienaar2019-03-291-12/+7
| | | | | | | * Matching an attribute and specifying a attribute constraint is the same thing executionally, so represent it such. * Extract AttrConstraint helper to match TypeConstraint and use that where mAttr was previously used in RewriterGen. PiperOrigin-RevId: 231213580
* Pull TableGen op argument definitions into their own filesLei Zhang2019-03-291-10/+12
| | | | PiperOrigin-RevId: 230923050
* Support op removal patterns in TableGenLei Zhang2019-03-291-15/+59
| | | | | | | | | | This CL adds a new marker, replaceWithValue, to indicate that no new result op is generated by applying a pattern. Instead, the matched DAG is replaced by an existing SSA value. Converted the tf.Identity converter to use the pattern. PiperOrigin-RevId: 230922323
* Simple CPU runnerAlex Zinenko2019-03-291-0/+162
| | | | | | | | | | | | | | | | | | | | | | | | | | This implements a simple CPU runner based on LLVM Orc JIT. The base functionality is provided by the ExecutionEngine class that compiles and links the module, and provides an interface for obtaining function pointers to the JIT-compiled MLIR functions and for invoking those functions directly. Since function pointers need to be casted to the correct pointer type, the ExecutionEngine wraps LLVM IR functions obtained from MLIR into a helper function with the common signature `void (void **)` where the single argument is interpreted as a list of pointers to the actual arguments passed to the function, eventually followed by a pointer to the result of the function. Additionally, the ExecutionEngine is set up to resolve library functions to those available in the current process, enabling support for, e.g., simple C library calls. For integration purposes, this also provides a simplistic runtime for memref descriptors as expected by the LLVM IR code produced by MLIR translation. In particular, memrefs are transformed into LLVM structs (can be mapped to C structs) with a pointer to the data, followed by dynamic sizes. This implementation only supports statically-shaped memrefs of type float, but can be extened if necessary. Provide a binary for the runner and a test that exercises it. PiperOrigin-RevId: 230876363
* Introduce a new operation hook point for implementing simple localChris Lattner2019-03-291-13/+22
| | | | | | | | | | | canonicalizations of operations. The ultimate important user of this is going to be a funcBuilder->foldOrCreate<YourOp>(...) API, but for now it is just a more convenient way to write certain classes of canonicalizations (see the change in StandardOps.cpp). NFC. PiperOrigin-RevId: 230770021
* Fixing op description white space during doc emission.Jacques Pienaar2019-03-291-2/+42
| | | | | | Strip additional whitespacing before and only add required additional indentation back. PiperOrigin-RevId: 230426127
* Add default attr value & define tf.AvgPool op and use pattern for rewrite.Jacques Pienaar2019-03-291-6/+38
| | | | | | | | | | | Add default values to attributes, to allow attribute being left unspecified. The attr getter will always return an attribute so callers need not check for it, if the attribute is not set then the default will be returned (at present the default will be constructed upon query but this will be changed). Add op definition for tf.AvgPool in ops.td, rewrite matcher using pattern using attribute matching & transforms. Adding some helper functions to make it simpler. Handle attributes with dialect prefix and map them to getter without dialect prefix. Note: VerifyAvgPoolOp could probably be autogenerated by know given the predicate specification on attributes, but deferring that to a follow up. PiperOrigin-RevId: 230364857
* Start doc generation pass.Jacques Pienaar2019-03-294-9/+101
| | | | | | | | | | Start doc generation pass that generates simple markdown output. The output is formatted simply[1] in markdown, but this allows seeing what info we have, where we can refine the op description (e.g., the inputs is probably redundant), what info is missing (e.g., the attributes could probably have a description). The formatting of the description is still left up to whatever was in the op definition (which luckily, due to the uniformity in the .td file, turned out well but relying on the indentation there is fragile). The mechanism to autogenerate these post changes has not been added yet either. The output file could be run through a markdown formatter too to remove extra spaces. [1]. This is not proposal for final style :) There could also be a discussion around single doc vs multiple (per dialect, per op), whether we want a TOC, whether operands/attributes should be headings or just formatted differently ... PiperOrigin-RevId: 230354538
* Add AttrConstraint to enable generating verification for attribute values.Jacques Pienaar2019-03-291-0/+9
| | | | | | | Change MinMaxAttr to match hasValidMinMaxAttribute behavior. Post rewriting the other users of that function it could be removed too. The currently generated error message is: error: 'tfl.fake_quant' op attribute 'minmax' failed to satisfy constraint of MinMaxAttr PiperOrigin-RevId: 229775631
* Generate some of the boilerplate for reference implementation specificationJacques Pienaar2019-03-291-5/+34
| | | | PiperOrigin-RevId: 229735735
* TableGen: implement predicate tree and basic simplificationAlex Zinenko2019-03-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | A recent change in TableGen definitions allowed arbitrary AND/OR predicate compositions at the cost of removing known-true predicate simplification. Introduce a more advanced simplification mechanism instead. In particular, instead of folding predicate C++ expressions directly in TableGen, keep them as is and build a predicate tree in TableGen C++ library. The predicate expression-substitution mechanism, necessary to implement complex predicates for nested classes such as `ContainerType`, is replaced by a dedicated predicate. This predicate appears in the predicate tree and can be used for tree matching and separation. More specifically, subtrees defined below such predicate may be subject to different transformations than those that appear above. For example, a subtree known to be true above the substitution predicate is not necessarily true below it. Use the predicate tree structure to eliminate known-true and known-false predicates before code emission, as well as to collapse AND and OR predicates if their value can be deduced based on the value of one child. PiperOrigin-RevId: 229605997
* Enable specifying the op for which the reference implementation should be ↵Jacques Pienaar2019-03-291-10/+12
| | | | | | | | printed. Allows emitting reference implementation of multiple ops inside the test lowering pass. PiperOrigin-RevId: 229603494
* Add attribute matching and transform to pattern rewrites.Jacques Pienaar2019-03-292-22/+57
| | | | | | | | Start simple with single predicate match & transform rules for attributes. * Its unclear whether modelling Attr predicates will be needed so start with allowing matching attributes with a single predicate. * The input and output attr type often differs and so add ability to specify a transform between the input and output format. PiperOrigin-RevId: 229580879
* Start a testing pass for EDSC lowering.Jacques Pienaar2019-03-291-0/+69
| | | | | | This is mostly plumbing to start allowing testing EDSC lowering. Prototype specifying reference implementation using verbose format without any generation/binding support. Add test pass that dumps the constructed EDSC (of which there can only be one). The idea is to enable iterating from multiple sides, this is wrong on many dimensions at the moment. PiperOrigin-RevId: 229570535
* TableGen: untie Attr from TypeAlex Zinenko2019-03-291-14/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | In TableGen definitions, the "Type" class has been used for types of things that can be stored in Attributes, but not necessarily present in the MLIR type system. As a consequence, records like "String" or "DerviedAttrBody" were of class "Type", which can be confusing. Furthermore, the "builderCall" field of the "Type" class serves only for attribute construction. Some TableGen "Type" subclasses that correspond to MLIR kinds of types do not have a canonical way of construction only from the data available in TableGen, e.g. MemRefType would require the list of affine maps. This leads to a conclusion that the entities that describe types of objects appearing in Attributes should be independent of "Type": they have some properties "Type"s don't and vice versa. Do not parameterize Tablegen "Attr" class by an instance of "Type". Instead, provide a "constBuilderCall" field that can be used to build an attribute from a constant value stored in TableGen instead of indirectly going through Attribute.Type.builderCall. Some attributes still don't have a "constBuilderCall" because they used to depend on types without a "builderCall". Drop definitions of class "Type" that don't correspond to MLIR Types. Provide infrastructure to define type-dependent attributes and string-backed attributes for convenience. PiperOrigin-RevId: 229570087
* Rename hasCanonicalizationPatterns to hasCanonicalizerLei Zhang2019-03-291-1/+1
| | | | | | | The latter is shorter but still conveys the idea clearly. It is also more consistent with hasConstantFolder. PiperOrigin-RevId: 229561774
* TableGen: extract TypeConstraints from TypeAlex Zinenko2019-03-292-7/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MLIR has support for type-polymorphic instructions, i.e. instructions that may take arguments of different types. For example, standard arithmetic operands take scalars, vectors or tensors. In order to express such instructions in TableGen, we need to be able to verify that a type object satisfies certain constraints, but we don't need to construct an instance of this type. The existing TableGen definition of Type requires both. Extract out a TypeConstraint TableGen class to define restrictions on types. Define the Type TableGen class as a subclass of TypeConstraint for consistency. Accept records of the TypeConstraint class instead of the Type class as values in the Arguments class when defining operators. Replace the predicate logic TableGen class based on conjunctive normal form with the predicate logic classes allowing for abitrary combinations of predicates using Boolean operators (AND/OR/NOT). The combination is implemented using simple string rewriting of C++ expressions and, therefore, respects the short-circuit evaluation order. No logic simplification is performed at the TableGen level so all expressions must be valid C++. Maintaining CNF using TableGen only would have been complicated when one needed to introduce top-level disjunction. It is also unclear if it could lead to a significantly simpler emitted C++ code. In the future, we may replace inplace predicate string combination with a tree structure that can be simplified in TableGen's C++ driver. Combined, these changes allow one to express traits like ArgumentsAreFloatLike directly in TableGen instead of relying on C++ trait classes. PiperOrigin-RevId: 229398247
* Avoid redundant predicate checking in type matching.Jacques Pienaar2019-03-291-2/+2
| | | | | | | | Expand type matcher template generator to consider a set of predicates that are known to hold. This avoids inserting redundant checking for trivially true predicates (for example predicate that hold according to the op definition). This only targets predicates that trivially holds and does not attempt any logic equivalence proof. PiperOrigin-RevId: 228880468
OpenPOWER on IntegriCloud