summaryrefslogtreecommitdiffstats
path: root/mlir/test/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Normalize MemRefType lowering to LLVM as strided MemRef descriptorNicolas Vasilache2019-09-301-2/+2
| | | | | | | | | | | | | | | | | | | | | This CL finishes the implementation of the lowering part of the [strided memref RFC](https://groups.google.com/a/tensorflow.org/forum/#!topic/mlir/MaL8m2nXuio). Strided memrefs correspond conceptually to the following templated C++ struct: ``` template <typename Elem, size_t Rank> struct { Elem *ptr; int64_t offset; int64_t sizes[Rank]; int64_t strides[Rank]; }; ``` The linearization procedure for address calculation for strided memrefs is the same as for linalg views: `base_offset + SUM_i index_i * stride_i`. The following CL will unify Linalg and Standard by removing !linalg.view in favor of strided memrefs. PiperOrigin-RevId: 272033399
* Fix MemRefType::getStrides corner caseNicolas Vasilache2019-09-301-1/+1
| | | | | | | | MemRefType::getStrides uses AffineExpr::walk which operates in post-order from the leaves. In order to compute strides properly, it needs to escape on terminal nodes and analyze binary ops only. This did not work for AffineExpr that consist of a single term (i.e. without a binary op). This CL fixes the corner case and adds relevant tests. PiperOrigin-RevId: 271975746
* Add InferTypeOpTrait & enable generating its member function definitionJacques Pienaar2019-09-294-2/+60
| | | | | | | | | | Use OpInterfaces to add an interface for ops defining a return type function. This change does not use this trait in any meaningful way, I'll use it in a follow up to generalize and unify some of the op type traits/constraints. Also, currently the infer type function can only be manually specified in C++, that should rather be the fallback in future. PiperOrigin-RevId: 271883746
* Tablegen helpers for accessing properties of shaped typesGeoffrey Martin-Noble2019-09-271-3/+2
| | | | | | Tablegen's lack of functions continues to be annoying PiperOrigin-RevId: 271680947
* Emit function name being tested in TestMemRefStrideCalculationJacques Pienaar2019-09-251-0/+1
| | | | | | Bring back CHECK-LABEL post PiperOrigin-RevId: 271166428
* Add tablegen verification traits for comparing different propertiesGeoffrey Martin-Noble2019-09-251-0/+12
| | | | | | This allows things like comparing the rank of one operand to the size of another that specifies indices into it. PiperOrigin-RevId: 271150439
* Fix memref-stride-calculation on WindowsLei Zhang2019-09-251-0/+1
| | | | | | | | Call llvm::outs().flush() to make sure we don't mix streams. Remove CHECK-LABEL to avoid assuming the relative order between the additional info and the output IR. PiperOrigin-RevId: 271131100
* Add initial callgraph support.River Riddle2019-09-232-0/+40
| | | | | | | | | | | | | | Using the two call interfaces, CallOpInterface and CallableOpInterface, this change adds support for an initial multi-level CallGraph. This call graph builds a set of nodes for each callable region, and connects them via edges. An edge may be any of the following types: * Abstract - An edge not produced by a call operation, used for connecting to internal nodes from external nodes. * Call - A call edge is an edge defined via a call-like operation. * Child - This is an artificial edge connecting nested callgraph nodes. This callgraph will be used, and improved upon, to begin supporting more interesting interprocedural analyses and transformation. In a followup, this callgraph will be used to support more complex inlining support. PiperOrigin-RevId: 270724968
* Add interfaces for call-like/callable operations.River Riddle2019-09-232-4/+11
| | | | | | | | | | | These two operation interfaces will be used in a followup to support building a callgraph: * CallOpInterface - Operations providing this interface are call-like, and have a "call" target. A call target may be a symbol reference, via SymbolRefAttr, or a SSA value. * CallableOpInterface - Operations providing this interfaces define destinations to call-like operations, e.g. FuncOp. These operations may define any number of callable regions. PiperOrigin-RevId: 270723300
* Fix a number of Clang-Tidy warnings.Christian Sigg2019-09-231-1/+1
| | | | PiperOrigin-RevId: 270632324
* [ODS] Add support for FloatElementsAttrLei Zhang2019-09-211-0/+17
| | | | | | | | | This CL adds a new FloatElementsAttr definition to ODS for float elements attributes of a certain type. Tests are added to show both verification and how to use it in patterns. PiperOrigin-RevId: 270455487
* NFC: Pass OpAsmPrinter by reference instead of by pointer.River Riddle2019-09-202-11/+11
| | | | | | MLIR follows the LLVM style of pass-by-reference. PiperOrigin-RevId: 270401378
* NFC: Pass OperationState by reference instead of by pointer.River Riddle2019-09-202-26/+26
| | | | | | MLIR follows the LLVM convention of passing by reference instead of by pointer. PiperOrigin-RevId: 270396945
* NFC: Pass OpAsmParser by reference instead of by pointer.River Riddle2019-09-202-18/+18
| | | | | | MLIR follows the LLVM style of pass-by-reference. PiperOrigin-RevId: 270315612
* Fix public buildNicolas Vasilache2019-09-201-0/+1
| | | | | | TestMemRefStrideCalculation.cpp was missing PiperOrigin-RevId: 270304543
* Add utility to extract strides from layout map in MemRefType.Nicolas Vasilache2019-09-201-0/+63
| | | | | | | | | | The RFC for unifying Linalg and Affine compilation passes into an end-to-end flow discusses the notion of a strided MemRef (https://groups.google.com/a/tensorflow.org/forum/#!topic/mlir/MaL8m2nXuio). This CL adds helper functions to extract strides from the layout map which in turn will allow converting between a strided form of the type and a layout map. For now strides are only computed on a single affine map with a single result (i.e. the closed subset of linearization maps that are compatible with striding semantics). This restriction will be reevaluated / lifted in the future based on concrete use cases. PiperOrigin-RevId: 270284686
* Add support to OpAsmParser for parsing unknown keywords.River Riddle2019-09-172-3/+28
| | | | | | This is useful in several cases, for example a user may want to sugar the syntax of a string(as we do with custom operation syntax), or avoid many nested ifs for parsing a set of known keywords. PiperOrigin-RevId: 269695451
* Add support for multi-level value mapping to DialectConversion.River Riddle2019-09-162-4/+90
| | | | | | When performing A->B->C conversion, an operation may still refer to an operand of A. This makes it necessary to unmap through multiple levels of replacement for a specific value. PiperOrigin-RevId: 269367859
* Publicly expose the functionality to parse a textual pass pipeline.River Riddle2019-09-131-0/+8
| | | | | | This allows for users other than those on the command line to apply a textual description of a pipeline to a given pass manager. PiperOrigin-RevId: 269017028
* Add type constraints for shaped types with same rank and element countGeoffrey Martin-Noble2019-09-131-0/+19
| | | | PiperOrigin-RevId: 269000237
* NFC: Finish replacing FunctionPassBase/ModulePassBase with OpPassBase.River Riddle2019-09-134-4/+4
| | | | | | These directives were temporary during the generalization of FunctionPass/ModulePass to OpPass. PiperOrigin-RevId: 268970259
* Add tablegen class for memrefs with rank constraintsGeoffrey Martin-Noble2019-09-131-0/+4
| | | | PiperOrigin-RevId: 268968004
* Refactor pass pipeline command line parsing to support explicit pipeline ↵River Riddle2019-09-131-1/+6
| | | | | | | | | | | | | | | | strings. This allows for explicitly specifying the pipeline to add to the pass manager. This includes the nesting structure, as well as the passes/pipelines to run. A textual pipeline string is defined as a series of names, each of which may in itself recursively contain a nested pipeline description. A name is either the name of a registered pass, or pass pipeline, (e.g. "cse") or the name of an operation type (e.g. "func"). For example, the following pipeline: $ mlir-opt foo.mlir -cse -canonicalize -lower-to-llvm Could now be specified as: $ mlir-opt foo.mlir -pass-pipeline='func(cse, canonicalize), lower-to-llvm' This will allow for running pipelines on nested operations, like say spirv modules. This does not remove any of the current functionality, and in fact can be used in unison. The new option is available via 'pass-pipeline'. PiperOrigin-RevId: 268954279
* Add `parseGenericOperation()` to the OpAsmParserMehdi Amini2019-09-082-0/+50
| | | | | | | | | This method parses an operation in its generic form, from the current parser state. This is the symmetric of OpAsmPrinter::printGenericOp(). An immediate use case is illustrated in the test dialect, where an operation wraps another one in its region and makes use of a single-line pretty-print form. PiperOrigin-RevId: 267930869
* Refactor PassTiming to support nested pipelines.River Riddle2019-09-083-0/+60
| | | | | | This is done via a new set of instrumentation hooks runBeforePipeline/runAfterPipeline, that signal the lifetime of a pass pipeline on a specific operation type. These hooks also provide the parent thread of the pipeline, allowing for accurate merging of timers running on different threads. PiperOrigin-RevId: 267909193
* Use "final" instead of marking method virtual in override (NFC)Mehdi Amini2019-09-071-1/+1
| | | | | | | | This is the only example for overriding this interface in the repo, let's try to make it right as it may be taken as a reference when implemented in other dialects PiperOrigin-RevId: 267811123
* Add the initial inlining infrastructure.River Riddle2019-09-054-1/+124
| | | | | | | | | | | | | | | | | | This defines a set of initial utilities for inlining a region(or a FuncOp), and defines a simple inliner pass for testing purposes. A new dialect interface is defined, DialectInlinerInterface, that allows for dialects to override hooks controlling inlining legality. The interface currently provides the following hooks, but these are just premilinary and should be changed/added to/modified as necessary: * isLegalToInline - Determine if a region can be inlined into one of this dialect, *or* if an operation of this dialect can be inlined into a given region. * shouldAnalyzeRecursively - Determine if an operation with regions should be analyzed recursively for legality. This allows for child operations to be closed off from the legality checks for operations like lambdas. * handleTerminator - Process a terminator that has been inlined. This cl adds support for inlining StandardOps, but other dialects will be added in followups as necessary. PiperOrigin-RevId: 267426759
* Generalize I32ElementsAttr definition and introduce I64ElementsAttrSmit Hinsu2019-09-041-1/+7
| | | | | | Also, fix constBuilderCall to return attribute of the storage class DenseIntElementsAttr PiperOrigin-RevId: 267305813
* Add a new dialect interface for the OperationFolder `OpFolderDialectInterface`.River Riddle2019-09-013-1/+25
| | | | | | This interface will allow for providing hooks to interrop with operation folding. The first hook, 'shouldMaterializeInto', will allow for controlling which region to insert materialized constants into. The folder will generally materialize constants into the top-level isolated region, this allows for materializing into a lower level ancestor region if it is more profitable/correct. PiperOrigin-RevId: 266702972
* Add TensorRankOf for ranked tensor types with specific ranksLogan Chien2019-08-301-3/+12
| | | | | | | | | This commit adds `TensorRankOf<types, typeNames, ranks>` to specify ranked tensor types with the specified types and ranks. For example, `TensorRankOf<[I32, F32], ["i32", "F32"], [0, 1]>` matches `tensor<i32>`, `tensor<?xi32>`, `tensor<f32>`, or `tensor<?xf32>`. PiperOrigin-RevId: 266461256
* Refactor the 'walk' methods for operations.River Riddle2019-08-292-2/+2
| | | | | | | | | | | | This change refactors and cleans up the implementation of the operation walk methods. After this refactoring is that the explicit template parameter for the operation type is no longer needed for the explicit op walks. For example: op->walk<AffineForOp>([](AffineForOp op) { ... }); is now accomplished via: op->walk([](AffineForOp op) { ... }); PiperOrigin-RevId: 266209552
* Add implementation for tensor_load and tensor_store operations.Stephan Herhut2019-08-281-0/+11
| | | | | | This change adds definitions, parsing and verification for both ops. PiperOrigin-RevId: 265954051
* NFC: Remove the explicit context from Operation::create and OperationState.River Riddle2019-08-261-2/+3
| | | | | | The context can easily be recovered from the Location in these situations. PiperOrigin-RevId: 265578574
* Support folding of ops with inner ops in GreedyPatternRewriteDriver.Andy Ly2019-08-262-5/+24
| | | | | | This fixes a bug when folding ops with inner ops and inner ops are still being visited. PiperOrigin-RevId: 265475780
* Introduce the ability for "isolated from above" ops to introduce shadowingChris Lattner2019-08-232-0/+8
| | | | | | names for the basic block arguments in their body. PiperOrigin-RevId: 265084627
* Add I32ElementsAttr to OpBaseMLIR Team2019-08-221-0/+4
| | | | PiperOrigin-RevId: 264969142
* Add Positive{I32,I64}Attr and HasAnyRankOfPredLogan Chien2019-08-221-0/+14
| | | | | | | | This commit adds `PositiveI32Attr` and `PositiveI64Attr` to match positive integers but not zero nor negative integers. This commit also adds `HasAnyRankOfPred` to match tensors with the specified ranks. PiperOrigin-RevId: 264867046
* [TableGen] Add a `StaticShapeMemRefOf` trait.MLIR Team2019-08-211-0/+4
| | | | | | The trait specifies that the `MemRefOf` has to have a static shape. PiperOrigin-RevId: 264692758
* Support variadic ops in declarative rewrite rulesLei Zhang2019-08-211-0/+110
| | | | | | | | | | | | | | | | | | | | | | | | This CL extends declarative rewrite rules to support matching and generating ops with variadic operands/results. For this, the generated `matchAndRewrite()` method for each pattern now are changed to * Use "range" types for the local variables used to store captured values (`operand_range` for operands, `ArrayRef<Value *>` for values, *Op for results). This allows us to have a unified way of handling both single values and value ranges. * Create local variables for each operand for op creation. If the operand is variadic, then a `SmallVector<Value*>` will be created to collect all values for that operand; otherwise a `Value*` will be created. * Use a collective result type builder. All result types are specified via a single parameter to the builder. We can use one result pattern to replace multiple results of the matched root op. When that happens, it will require specifying types for multiple results. Add a new collective-type builder. PiperOrigin-RevId: 264588559
* NFC: Move AffineOps dialect to the Dialect sub-directory.River Riddle2019-08-203-3/+3
| | | | PiperOrigin-RevId: 264482571
* Allow isolated regions to form isolated SSA name scopes in the printer.River Riddle2019-08-192-5/+34
| | | | | | | | | | | This will allow for naming values the same as existing SSA values for regions attached to operations that are isolated from above. This fits in with how the system already allows separate name scopes for sibling regions. This name shadowing can be enabled in the custom parser of operations by setting the 'enableNameShadowing' flag to true when calling 'parseRegion'. %arg = constant 10 : i32 foo.op { %arg = constant 10 : i32 } PiperOrigin-RevId: 264255999
* NFC: Move LLVMIR, SDBM, and StandardOps to the Dialect/ directory.River Riddle2019-08-192-2/+2
| | | | PiperOrigin-RevId: 264193915
* Change from llvm::make_unique to std::make_uniqueJacques Pienaar2019-08-176-7/+7
| | | | | | | | 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
* Express ownership transfer in PassManager API through std::unique_ptr (NFC)Mehdi Amini2019-08-126-13/+17
| | | | | | | | | | | | | | Since raw pointers are always passed around for IR construct without implying any ownership transfer, it can be error prone to have implicit ownership transferred the same way. For example this code can seem harmless: Pass *pass = .... pm.addPass(pass); pm.addPass(pass); pm.run(module); PiperOrigin-RevId: 263053082
* NFC: Standardize the terminology used for parent ops/regions/etc.River Riddle2019-08-093-3/+3
| | | | | | There are currently several different terms used to refer to a parent IR unit in 'get' methods: getParent/getEnclosing/getContaining. This cl standardizes all of these methods to use 'getParent*'. PiperOrigin-RevId: 262680287
* NFC: Update usages of OwningRewritePatternList to pass by & instead of &&.River Riddle2019-08-091-4/+3
| | | | | | This will allow for reusing the same pattern list, which may be costly to continually reconstruct, on multiple invocations. PiperOrigin-RevId: 262664599
* Remove ops in regions/blocks from worklist when parent op is being removed ↵Andy Ly2019-08-062-0/+27
| | | | | | | | via GreedyPatternRewriteDriver::replaceOp. This fixes a bug where ops inside the parent op are visited even though the parent op has been removed. PiperOrigin-RevId: 261953580
* NFC: Implement OwningRewritePatternList as a class instead of a using directive.River Riddle2019-08-051-4/+4
| | | | | | This allows for proper forward declaration, as opposed to leaking the internal implementation via a using directive. This also allows for all pattern building to go through 'insert' methods on the OwningRewritePatternList, replacing uses of 'push_back' and 'RewriteListBuilder'. PiperOrigin-RevId: 261816316
* [ODS] Add new definitions for non-negative integer attributesLei Zhang2019-08-031-0/+7
| | | | | | | This CL added a new NonNegativeIntAttrBase class and two instantiations, one for I32 and the other for I64. PiperOrigin-RevId: 261513292
* Replace the verifyUnusedValue directive with HasNoUseOf constraintLei Zhang2019-08-011-17/+1
| | | | | | | | | 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
OpenPOWER on IntegriCloud