summaryrefslogtreecommitdiffstats
path: root/mlir/tools
Commit message (Collapse)AuthorAgeFilesLines
...
* [TableGen] Support benefit score in pattern definition.Feng Liu2019-03-291-5/+1
| | | | | | | | 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
* Remove global LLVM CLI variables from library codeDimitrios Vytiniotis2019-03-291-6/+49
| | | | | | Plus move parsing code into the MLIR CPU runner binary. PiperOrigin-RevId: 240786709
* Replace remaining usages of the Instruction class with Operation.River Riddle2019-03-293-9/+9
| | | | PiperOrigin-RevId: 240777521
* [TableGen] Change names for Builder* and OperationState* parameters to avoid ↵Lei Zhang2019-03-291-16/+24
| | | | | | | | | | | collision The `Builder*` parameter is unused in both generated build() methods so that we can leave it unnamed. Changed stand-alone parameter build() to take `_tblgen_state` instead of `result` to allow `result` to avoid having name collisions with op operand, attribute, or result. PiperOrigin-RevId: 240637700
* Add missing numeric header for std::accumulate.Jacques Pienaar2019-03-291-0/+1
| | | | PiperOrigin-RevId: 240593135
* Replace usages of Instruction with Operation in the /IR directory.River Riddle2019-03-292-8/+8
| | | | | | This is step 2/N to renaming Instruction to Operation. PiperOrigin-RevId: 240459216
* Add a trait to set the result type by attributeFeng Liu2019-03-292-11/+33
| | | | | | | | | 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
* Replace usages of "Op::operator->" with ".".River Riddle2019-03-291-5/+5
| | | | | | This is step 2/N of removing the temporary operator-> method as part of the de-const transition. PiperOrigin-RevId: 240200792
* Qualify string in OpDefinitionsGen. NFC.Jacques Pienaar2019-03-291-1/+1
| | | | PiperOrigin-RevId: 240188138
* [TableGen] Consolidate constraint related conceptsLei Zhang2019-03-291-29/+31
| | | | | | | | | | | | | | | | | | | 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
* Using getContext() instead of getInstruction()->getContext() on Operation (NFC)Mehdi Amini2019-03-291-8/+6
| | | | PiperOrigin-RevId: 240088209
* Remove OpPointer, cleaning up a ton of code. This also moves Ops to usingChris Lattner2019-03-291-4/+2
| | | | | | | | | inherited constructors, which is cleaner and means you can now use DimOp() to get a null op, instead of having to use Instruction::getNull<DimOp>(). This removes another 200 lines of code. PiperOrigin-RevId: 240068113
* Fix missing parenthesis around negation.Jacques Pienaar2019-03-291-2/+2
| | | | | | This should probably be changed to instead use the negated form (e.g., get predicate + negate it + get resulting template), but this fixes it locally. PiperOrigin-RevId: 240067116
* Remove const from Value, Instruction, Argument, and the various methods on theChris Lattner2019-03-291-2/+1
| | | | | | *Op classes. This is a net reduction by almost 400LOC. PiperOrigin-RevId: 239972443
* Return operand_range instead for generated variadic operands accessor.Jacques Pienaar2019-03-291-8/+6
| | | | PiperOrigin-RevId: 239959381
* Now that ConstOpPointer is gone, we can change the various methods generated byChris Lattner2019-03-291-40/+11
| | | | | | | | | | tblgen be non-const. This requires introducing some const_cast's at the moment, but those (and lots more stuff) will disappear in subsequent patches. This significantly simplifies those patches because the various tblgen op emitters get adjusted. PiperOrigin-RevId: 239954566
* Verify first body is not empty before testing last character.Jacques Pienaar2019-03-291-1/+1
| | | | | | Avoids sigabrt where body is empty. PiperOrigin-RevId: 239942200
* Continue pushing const out of the IR types - removing the notion of a 'constChris Lattner2019-03-291-2/+1
| | | | | | Module'. NFC. PiperOrigin-RevId: 239532885
* [TableGen] Generate op declaration and definition into different filesLei Zhang2019-03-291-273/+583
| | | | | | | | | | | | | Previously we emit both op declaration and definition into one file and include it in *Ops.h. That pulls in lots of implementation details in the header file and we cannot hide symbols local to implementation. This CL splits them to provide a cleaner interface. The way how we define custom builders in TableGen is changed accordingly because now we need to distinguish signatures and implementation logic. Some custom builders with complicated logic now can be moved to be implemented in .cpp entirely. PiperOrigin-RevId: 239509594
* Remove some statements that required >C++11, add includes and qualify names. ↵Jacques Pienaar2019-03-291-2/+2
| | | | | | NFC. PiperOrigin-RevId: 239197784
* Cleanups for OSS build.Jacques Pienaar2019-03-291-1/+1
| | | | PiperOrigin-RevId: 238999629
* Change Value to NamedTypeConstraint and use TypeConstraint.Jacques Pienaar2019-03-293-16/+17
| | | | | | 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
* Port Tablegen'd reference implementation of Add to declarative builders.Nicolas Vasilache2019-03-291-20/+23
| | | | PiperOrigin-RevId: 238977252
* Moving the IR printing and execution timing options out of mlir-opt and into ↵River Riddle2019-03-291-89/+8
| | | | | | lib/Pass. We now expose two methods: registerPassManagerCLOptions and applyPassManagerCLOptions; to allow for multiple different users (mlir-opt, etc.) to opt-in to this common functionality. PiperOrigin-RevId: 238836911
* Remove unnecessary headers from mlir-opt.Jacques Pienaar2019-03-291-5/+0
| | | | PiperOrigin-RevId: 238639013
* Add an instrumentation for conditionally printing the IR before and after ↵River Riddle2019-03-291-2/+71
| | | | | | | | | | | | | | | | | pass execution. This instrumentation can be added directly to the PassManager via 'enableIRPrinting'. mlir-opt exposes access to this instrumentation via the following flags: * print-ir-before=(comma-separated-pass-list) - Print the IR before each of the passes provided within the pass list. * print-ir-before-all - Print the IR before every pass in the pipeline. * print-ir-after=(comma-separated-pass-list) - Print the IR after each of the passes provided within the pass list. * print-ir-after-all - Print the IR after every pass in the pipeline. * print-ir-module-scope - Always print the Module IR, even for non module passes. PiperOrigin-RevId: 238523649
* [TableGen] Support nested dag attributes arguments in the result patternFeng Liu2019-03-291-34/+68
| | | | | | | | | | 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
* Refactor pass timing so that it is toggled on the passmanager via ↵River Riddle2019-03-291-6/+5
| | | | | | 'enableTiming'. This also makes the pipeline view the default display mode. PiperOrigin-RevId: 238079916
* Ensure that pass timing is the last added pass instrumentation. This also ↵River Riddle2019-03-291-1/+1
| | | | | | updates the PassInstrumentor to iterate in reverse for the "after" hooks. This ensures that the instrumentations run in a stack like fashion. PiperOrigin-RevId: 237840808
* Add a new instrumentation for timing pass and analysis execution. This is ↵River Riddle2019-03-291-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | made available in mlir-opt via the 'pass-timing' and 'pass-timing-display' flags. The 'pass-timing-display' flag toggles between the different available display modes for the timing results. The current display modes are 'list' and 'pipeline', with 'list' representing the default. Below shows the output for an example mlir-opt command line. mlir-opt foo.mlir -verify-each=false -cse -canonicalize -cse -cse -pass-timing list view (-pass-timing-display=list): * In this mode the results are displayed in a list sorted by total time; with each pass/analysis instance aggregated into one unique result. This mode is similar to the output of 'time-passes' in llvm-opt. ===-------------------------------------------------------------------------=== ... Pass execution timing report ... ===-------------------------------------------------------------------------=== Total Execution Time: 0.0097 seconds (0.0096 wall clock) ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name --- 0.0051 ( 58.3%) 0.0001 ( 12.2%) 0.0052 ( 53.8%) 0.0052 ( 53.8%) Canonicalizer 0.0025 ( 29.1%) 0.0005 ( 58.2%) 0.0031 ( 31.9%) 0.0031 ( 32.0%) CSE 0.0011 ( 12.6%) 0.0003 ( 29.7%) 0.0014 ( 14.3%) 0.0014 ( 14.2%) DominanceInfo 0.0087 (100.0%) 0.0009 (100.0%) 0.0097 (100.0%) 0.0096 (100.0%) Total pipeline view (-pass-timing-display=pipeline): * In this mode the results are displayed in a nested pipeline view that mirrors the internal pass pipeline that is being executed in the pass manager. This view is useful for understanding specifically which parts of the pipeline are taking the most time, and can also be used to identify when analyses are being invalidated and recomputed. ===-------------------------------------------------------------------------=== ... Pass execution timing report ... ===-------------------------------------------------------------------------=== Total Execution Time: 0.0082 seconds (0.0081 wall clock) ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name --- 0.0042 (100.0%) 0.0039 (100.0%) 0.0082 (100.0%) 0.0081 (100.0%) Function Pipeline 0.0005 ( 11.6%) 0.0008 ( 21.1%) 0.0013 ( 16.1%) 0.0013 ( 16.2%) CSE 0.0002 ( 5.0%) 0.0004 ( 9.3%) 0.0006 ( 7.0%) 0.0006 ( 7.0%) (A) DominanceInfo 0.0026 ( 61.8%) 0.0018 ( 45.6%) 0.0044 ( 54.0%) 0.0044 ( 54.1%) Canonicalizer 0.0005 ( 11.7%) 0.0005 ( 13.0%) 0.0010 ( 12.3%) 0.0010 ( 12.4%) CSE 0.0003 ( 6.1%) 0.0003 ( 8.3%) 0.0006 ( 7.2%) 0.0006 ( 7.1%) (A) DominanceInfo 0.0002 ( 3.8%) 0.0001 ( 2.8%) 0.0003 ( 3.3%) 0.0003 ( 3.3%) CSE 0.0042 (100.0%) 0.0039 (100.0%) 0.0082 (100.0%) 0.0081 (100.0%) Total PiperOrigin-RevId: 237825367
* Update the constantFold/fold API to use LogicalResult instead of bool.River Riddle2019-03-291-3/+3
| | | | PiperOrigin-RevId: 237719658
* Delete dead function.Jacques Pienaar2019-03-291-12/+0
| | | | | | Can reintroduce when needed. PiperOrigin-RevId: 237599264
* [TableGen] Change to attach the name to DAG operator in result patternsLei Zhang2019-03-291-14/+14
| | | | | | | | | | | | There are two ways that we can attach a name to a DAG node: 1) (Op:$name ...) 2) (Op ...):$name The problem with 2) is that we cannot do it on the outmost DAG node in a tree. Switch from 2) to 1). PiperOrigin-RevId: 237513962
* [TableGen] Support multiple result patternsLei Zhang2019-03-291-11/+56
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Update the PassManager infrastructure to return Status instead of bool.River Riddle2019-03-291-1/+1
| | | | PiperOrigin-RevId: 237261205
* TableGen most of the LLVM IR Dialect to LLVM IR conversionsAlex Zinenko2019-03-292-4/+227
| | | | | | | | | | | | | | | | | | | | The LLVM IR Dialect strives to be close to the original LLVM IR instructions. The conversion from the LLVM IR Dialect to LLVM IR proper is mostly mechanical and can be automated. Implement TableGen support for generating conversions from a concise pattern form in the TableGen definition of the LLVM IR Dialect operations. It is used for all operations except calls and branches. These operations need access to function and block remapping tables and would require significantly more code to generate the conversions from TableGen definitions than the current manually written conversions. This implementation is accompanied by various necessary changes to the TableGen operation definition infrastructure. In particular, operation definitions now contain named accessors to results as well as named accessors to the variadic operand (returning a vector of operands). The base operation support TableGen file now contains a FunctionAttr definition. The TableGen now allows to query the names of the operation results. PiperOrigin-RevId: 237203077
* [TableGen] Emit verification code for op resultsLei Zhang2019-03-291-13/+23
| | | | | | They can be verified using the same logic as operands. PiperOrigin-RevId: 237101461
* TableGen: allow mixing attributes and operands in the Arguments DAG of Op ↵Alex Zinenko2019-03-291-18/+23
| | | | | | | | | | | | | | | | | | | 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-7/+7
| | | | | | 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: fix builder generation for optional attributesAlex Zinenko2019-03-291-4/+6
| | | | | | | | | | | | The recently introduced support for generating MLIR Operations with optional attributes did not handle the formatted string emission properly, in particular it did not escape `{` and `}` in calls to `formatv` leading to assertions during TableGen op definition generation. Fix this by splitting out the unncessary braces from the format string. Additionally, fix the emission of the builder argument comment to correctly indicate which attributes are indeed optional and which are not. PiperOrigin-RevId: 236832230
* Add a 'verifyPasses' flag to the PassManager that specifies if the IR should ↵River Riddle2019-03-291-3/+6
| | | | | | be verified after each pass. This also adds a "verify-each" flag to mlir-opt to optionally disable running the verifier after each pass. PiperOrigin-RevId: 236703760
* Remove PassResult and have the runOnFunction/runOnModule functions return ↵River Riddle2019-03-291-1/+1
| | | | | | void instead. To signal a pass failure, passes should now invoke the 'signalPassFailure' method. This provides the equivalent functionality when needed, but isn't an intrusive part of the API like PassResult. PiperOrigin-RevId: 236202029
* ExecutionEngine OptUtils: support -On flags in string-based initializationAlex Zinenko2019-03-291-33/+1
| | | | | | | | | | | | | | Original implementation of OutUtils provided two different LLVM IR module transformers to be used with the MLIR ExecutionEngine: OptimizingTransformer parameterized by the optimization levels (similar to -O3 flags) and LLVMPassesTransformer parameterized by the string formatted similarly to command line options of LLVM's "opt" tool without support for -O* flags. Introduce such support by declaring the flags inside the parser and by populating the pass managers similarly to what "opt" does. Remove the additional flags from mlir-cpu-runner as they can now be wrapped into `-llvm-opts` together with other LLVM-related flags. PiperOrigin-RevId: 236107292
* Add support for registering pass pipelines to the PassRegistry. This is done ↵River Riddle2019-03-291-5/+6
| | | | | | | | | | | | | | | | | | | by providing a static registration facility PassPipelineRegistration that works similarly to PassRegistration except for it also takes a function that will add necessary passes to a provided PassManager. void pipelineBuilder(PassManager &pm) { pm.addPass(new MyPass()); pm.addPass(new MyOtherPass()); } static PassPipelineRegistration Unused("unused", "Unused pass", pipelineBuilder); This is also useful for registering specializations of existing passes: Pass *createFooPass10() { return new FooPass(10); } static PassPipelineRegistration Unused("unused", "Unused pass", createFooPass10); PiperOrigin-RevId: 235996282
* Port all of the existing passes over to the new pass manager infrastructure. ↵River Riddle2019-03-291-11/+8
| | | | | | This is largely NFC. PiperOrigin-RevId: 235952357
* [TableGen] Use result names in build() methods if possibleLei Zhang2019-03-291-5/+15
| | | | | | This will make it clear which result's type we are expecting in the build() signature. PiperOrigin-RevId: 235925706
* [TableGen] Fix using rewrite()'s qualified name for a bound argument in match()Lei Zhang2019-03-291-9/+18
| | | | PiperOrigin-RevId: 235767304
* Verify IR produced by TranslateToMLIR functionsSmit Hinsu2019-03-291-2/+3
| | | | | | TESTED with existing unit tests PiperOrigin-RevId: 235623059
* [TableGen] Use ArrayRef instead of SmallVectorImpl for suitable methodLei Zhang2019-03-291-4/+4
| | | | PiperOrigin-RevId: 235577399
* Spike to define real math ops and lowering of one variant of add to ↵Stella Laurenzo2019-03-291-7/+19
| | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud