summaryrefslogtreecommitdiffstats
path: root/mlir/lib/IR/MLIRContext.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Adds ConstantFoldHook registry in MLIRContextFeng Liu2019-03-291-0/+13
| | | | | | | | | | | | | | This reverts the previous method which needs to create a new dialect with the constant fold hook from TensorFlow. This new method uses a function object in dialect to store the constant fold hook. Once a hook is registered to the dialect, this function object will be assigned when the dialect is added to the MLIRContext. For the operations which are not registered, a new method getRegisteredDialects is added to the MLIRContext to query the dialects which matches their op name prefixes. PiperOrigin-RevId: 222310149
* Add Type to int/float attributes.Jacques Pienaar2019-03-291-20/+28
| | | | | | | | | | | | * Optionally attach the type of integer and floating point attributes to the attributes, this allows restricting a int/float to specific width. - Currently this allows suffixing int/float constant with type [this might be revised in future]. - Default to i64 and f32 if not specified. * For index types the APInt width used is 64. * Change callers to request a specific attribute type. * Store iN type with APInt of width N. * This change does not handle the folding of constants of different types (e.g., doing int type promotions to support constant folding i3 and i32), and instead restricts the constant folding to only operate on the same types. PiperOrigin-RevId: 221722699
* Optionally emit errors from IntegerType factory functions.Alex Zinenko2019-03-291-3/+22
| | | | | | | | | | | | | | | Similarly to other types, introduce "get" and "getChecked" static member functions for IntegerType. The latter emits errors to the error handler registered with the MLIR context and returns a null type for the caller to handle errors gracefully. This deduplicates type consistency checks between the parser and the builder. Update the parser to call IntegerType::getChecked for error reporting instead of the builder that would simply assert. This CL completes the type system error emission refactoring: the parser now only emits syntax-related errors for types while type factory systems may emit type consistency errors. PiperOrigin-RevId: 221165207
* Switch IntegerAttr to use APInt.Jacques Pienaar2019-03-291-11/+46
| | | | | | | | Change the storage type to APInt from int64_t for IntegerAttr (following the change to APFloat storage in FloatAttr). Effectively a direct change from int64_t to 64-bit APInt throughout (the bitwidth hardcoded). This change also adds a getInt convenience method to IntegerAttr and replaces previous getValue calls with getInt calls. While this changes updates the storage type, it does not update all constant folding calls. PiperOrigin-RevId: 221082788
* - Add support for fused locations.River Riddle2019-03-291-3/+95
| | | | | | | | | | | | | | | | | | | | | | These are locations that form a collection of other source locations with an optional metadata attribute. - Add initial support for print/dump for locations. Location Printing Examples: * Unknown : [unknown-location] * FileLineColLoc : third_party/llvm/llvm/projects/google-mlir/test/TensorFlowLite/legalize.mlir:6:8 * FusedLoc : <"tfl-legalize">[third_party/llvm/llvm/projects/google-mlir/test/TensorFlowLite/legalize.mlir:6:8, third_party/llvm/llvm/projects/google-mlir/test/TensorFlowLite/legalize.mlir:7:8] - Add diagnostic support for fused locs. * Prints the first location as the main location and the remaining as "fused from here" notes: e.g. third_party/llvm/llvm/projects/google-mlir/test/TensorFlowLite/legalize.mlir:6:8: error: This is an error. %1 = "tf.add"(%arg0, %0) : (i32, i32) -> i32 ^ third_party/llvm/llvm/projects/google-mlir/test/TensorFlowLite/legalize.mlir:7:8: error: Fused from here. %2 = "tf.relu"(%1) : (i32) -> i32 ^ PiperOrigin-RevId: 220835552
* Clean up TensorType construction.Alex Zinenko2019-03-291-8/+62
| | | | | | | | | | | | This CL introduces the following related changes: - move tensor element type validity checking to a static member function TensorType::isValidElementType - introduce get/getChecked similarly to MemRefType, where the checked function emits errors and returns nullptrs; - remove duplicate element type validity checking from the parser and rely on the type constructor to emit errors instead. PiperOrigin-RevId: 220694831
* Clean up VectorType construction.Alex Zinenko2019-03-291-10/+45
| | | | | | | | | | | | This CL introduces the following related changes: - factor out element type validity checking to a static member function VectorType::isValidElementType; - introduce get/getChecked similarly to MemRefType, where the checked function emits errors and returns nullptrs; - remove duplicate element type validity checking from the parser and rely on the type constructor to emit errors instead. PiperOrigin-RevId: 220693828
* Implement value type abstraction for locations.River Riddle2019-03-291-24/+26
| | | | | | Value type abstraction for locations differ from others in that a Location can NOT be null. NOTE: dyn_cast returns an Optional<T>. PiperOrigin-RevId: 220682078
* Allow vector types to have index elements.Alex Zinenko2019-03-291-1/+2
| | | | | | | | | | It is unclear why vector types were not allowed to have "index" as element type. Index values are integers, although of unknown bit width, and should behave as such. Vectors of integers are allowed and so are tensors of indices (for indirection purposes), it is more consistent to also have vectors of indices. PiperOrigin-RevId: 220630123
* Enable arithmetics for index types.Alex Zinenko2019-03-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Arithmetic and comparison instructions are necessary to implement, e.g., control flow when lowering MLFunctions to CFGFunctions. (While it is possible to replace some of the arithmetics by affine_apply instructions for loop bounds, it is still necessary for loop bounds checking, steps, if-conditions, non-trivial memref subscripts, etc.) Furthermore, working with indirect accesses in, e.g., lookup tables for large embeddings, may require operating on tensors of indexes. For example, the equivalents to C code "LUT[Index[i]]" or "ResultIndex[i] = i + j" where i, j are loop induction variables require the arithmetics on indices as well as the possibility to operate on tensors thereof. Allow arithmetic and comparison operations to apply to index types by declaring them integer-like. Allow tensors whose element type is index for indirection purposes. The absence of vectors with "index" element type is explicitly tested, but the only justification for this restriction in the CL introducing the test is "because we don't need them". Do NOT enable vectors of index types, although it makes vector and tensor types inconsistent with respect to allowed element types. PiperOrigin-RevId: 220614055
* Materialize IndexType in the API.Alex Zinenko2019-03-291-0/+14
| | | | | | | | | | | | | | | Previously, index (aka affint) type was hidden under OtherType in the type API. We will need to identify and operate on values of index types in the upcoming MLFunc->CFGFunc(->LLVM) lowering passes. Materialize index type into a separate class and make it visible to LLVM RTTI hierarchy directly. Practically, index is an integer type of unknown bit width and is accetable in most places where regular integer types are. This is purely an API change that does not affect the IR. After IndexType is separated out from OtherType, the remaining "other types" are, in fact, TF-specific types only. Further renaming may be of interest. PiperOrigin-RevId: 220614026
* Uniformize MemRefType well-formedness checks.Alex Zinenko2019-03-291-8/+60
| | | | | | | | | | | | | | | | | | | | | | | Introduce a new public static member function, MemRefType::getChecked, intended for the users that want detailed error messages to be emitted during MemRefType construction and can gracefully handle these errors. This function takes a Location of the "MemRef" token if known. The parser is one user of getChecked that has location information, it outputs errors as compiler diagnostics. Other users may pass in an instance of UnknownLoc and still have error messages emitted. Compiler-internal users not expecting the MemRefType construction to fail should call MemRefType::get, which now aborts on failure with a generic message. Both "getChecked" and "get" call to a static free function that does actual construction with well-formedness checks, optionally emits errors and returns nullptr on failure. The location information passed to getChecked has voluntarily coarse precision. The error messages are intended for compiler engineers and do not justify heavier API than a single location. The text of the messages can be written so that it pinpoints the actual location of the error within a MemRef declaration. PiperOrigin-RevId: 219765902
* Implement value type abstraction for types.River Riddle2019-03-291-97/+110
| | | | | | This is done by changing Type to be a POD interface around an underlying pointer storage and adding in-class support for isa/dyn_cast/cast. PiperOrigin-RevId: 219372163
* [MLIR] Implement 1-D vectorization for fastest varying load/storesNicolas Vasilache2019-03-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL is a first in a series that implements early vectorization of increasingly complex patterns. In particular, early vectorization will support arbitrary loop nesting patterns (both perfectly and imperfectly nested), at arbitrary depths in the loop tree. This first CL builds the minimal support for applying 1-D patterns. It relies on an unaligned load/store op abstraction that can be inplemented differently on different HW. Future CLs will support higher dimensional patterns, but 1-D patterns already exhibit interesting properties. In particular, we want to separate pattern matching (i.e. legality both structural and dependency analysis based), from profitability analysis, from application of the transformation. As a consequence patterns may intersect and we need to verify that a pattern can still apply by the time we get to applying it. A non-greedy analysis on profitability that takes into account pattern intersection is left for future work. Additionally the CL makes the following cleanups: 1. the matches method now returns a value, not a reference; 2. added comments about the MLFunctionMatcher and MLFunctionMatches usage by value; 3. added size and empty methods to matches; 4. added a negative vectorization test with a conditional, this exhibited a but in the iterators. Iterators now return nullptr if the underlying storage is nullpt. PiperOrigin-RevId: 219299489
* Drop unbounded identity map from MemRef affine map composition.Alex Zinenko2019-03-291-6/+9
| | | | | | | | | | | | | | | | Unbounded identity maps do not affect the accesses through MemRefs in any way. A previous CL dropped such maps only if they were alone in the composition. Go further and drop such maps everywhere they appear in the composition. Update the parser test to check for unique'd hoisted map to be present but without assuming any particular order. Because some of the hoisted identity maps still apear due to the nested "for" statements, we need to check for them. However, they no longer appear above the non-identity maps because they are no longer necessary for the extfunc memref declarations that are textually first in the test file. This order may change further as map simplification is improved, there is no reason to assume a particular order. PiperOrigin-RevId: 219287280
* [trivial] fix MLIRContext::registerDiagnosticHandler documentationAlex Zinenko2019-03-291-3/+3
| | | | | | | | | The documentation for MLIRContext::registerDiagnosticHandler describing the arguments of the diagnostic handler is inconsistent with the code. It also mentions LLVM context rather than MLIR context, likely a typo. Fix both issues. PiperOrigin-RevId: 219120954
* Drop trivial identity affine mappings in MemRef construction.Alex Zinenko2019-03-291-0/+8
| | | | | | | | | | | | | | | | | | | As per MLIR spec, the absence of affine maps in MemRef type is interpreted as an implicit identity affine map. Therefore, MemRef types declared with explicit or implicit identity map should be considered equal at the MemRefType level. During MemRefType construction, drop trivial identity affine map compositions. A trivial identity composition consists of a single unbounded identity map. It is unclear whether affine maps should be composed in-place to a single map during MemRef type construction, so non-trivial compositions that could have been simplified to an identity are NOT removed. We chose to drop the trivial identity map rather than inject it in places that assume its present implicitly because it makes the code simpler by reducing boilerplate; identity mappings are obvious defaults. Update tests that were checking for the presence of trivial identity map compositions in the outputs. PiperOrigin-RevId: 218862454
* Introduce integer set attributeUday Bondhugula2019-03-291-0/+14
| | | | | | | - add IntegerSetAttr to Attributes; add parsing and other support for it (builder, etc.). PiperOrigin-RevId: 218804579
* Refactor all of the canonicalization patterns out of the Canonicalize pass, andChris Lattner2019-03-291-0/+33
| | | | | | | | | | make operations provide a list of canonicalizations that can be applied to them. This allows canonicalization to be general to any IR definition. As part of this, sink PatternMatch.h/cpp down to the IR library to fix a layering problem. PiperOrigin-RevId: 218773981
* Implement value type abstraction for attributes.River Riddle2019-03-291-197/+138
| | | | | | This is done by changing Attribute to be a POD interface around an underlying pointer storage and adding in-class support for isa/dyn_cast/cast. PiperOrigin-RevId: 218764173
* Introduce Fourier-Motzkin variable elimination + other cleanup/supportUday Bondhugula2019-03-291-15/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Introduce Fourier-Motzkin variable elimination to eliminate a dimension from a system of linear equalities/inequalities. Update isEmpty to use this. Since FM is only exact on rational/real spaces, an emptiness check based on this is guaranteed to be exact whenever it says the underlying set is empty; if it says, it's not empty, there may still be no integer points in it. Also, supports a version that computes "dark shadows". - Test this by checking for "always false" conditionals in if statements. - Unique IntegerSet's that are small (few constraints, few variables). This basically means the canonical empty set and other small sets that are likely commonly used get uniqued; allows checking for the canonical empty set by pointer. IntegerSet::kUniquingThreshold gives the threshold constraint size for uniqui'ing. - rename simplify-affine-expr -> simplify-affine-structures Other cleanup - IntegerSet::numConstraints, AffineMap::numResults are no longer needed; remove them. - add copy assignment operators for AffineMap, IntegerSet. - rename Invalid() -> Null() on AffineExpr, AffineMap, IntegerSet - Misc cleanup for FlatAffineConstraints API PiperOrigin-RevId: 218690456
* Add support to opaque elements attributesFeng Liu2019-03-291-0/+42
| | | | | | | | | | | | | For some of the constant vector / tesor, if the compiler doesn't need to interpret their elements content, they can be stored in this class to save the serialize / deserialize cost. syntax: `opaque<` tensor-type `,` opaque-string `>` opaque-string ::= `0x` [0-9a-fA-F]* PiperOrigin-RevId: 218399426
* Replace the "OperationSet" abstraction with a new Dialect abstraction. This isChris Lattner2019-03-291-9/+47
| | | | | | | | | a step forward because now every AbstractOperation knows which Dialect it is associated with, enabling things in the future like "constant folding hooks" which will be important for layering. This is also a bit nicer on the registration side of things. PiperOrigin-RevId: 218104230
* Use APFloat for FloatAttributeFeng Liu2019-03-291-16/+45
| | | | | | | | | | | | We should be able to represent arbitrary precision Float-point values inside the IR, so compiler optimizations, such as constant folding can be done independently on the compiling platform. This CL also added a new field, AttrValueGetter, to the Attr class definition for TableGen. This field is used to customize which mlir::Attr getter method to get the defined PrimitiveType. PiperOrigin-RevId: 218034983
* Touch an unused variable.MLIR Team2019-03-291-0/+1
| | | | PiperOrigin-RevId: 217861580
* Add support to constant sparse tensor / vector attributeFeng Liu2019-03-291-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | | The SparseElementsAttr uses (COO) Coordinate List encoding to represents a sparse tensor / vector. Specifically, the coordinates and values are stored as two dense elements attributes. The first dense elements attribute is a 2-D attribute with shape [N, ndims], which contains the indices of the elements with nonzero values in the constant vector/tensor. The second elements attribute is a 1-D attribute list with shape [N], which supplies the values for each element in the first elements attribute. ndims is the rank of the vector/tensor and N is the total nonzero elements. The syntax is: `sparse<` (tensor-type | vector-type)`, ` indices-attribute-list, values-attribute-list `>` Example: a sparse tensor sparse<vector<3x4xi32>, [[0, 0], [1, 2]], [1, 2]> represents the dense tensor [[1, 0, 0, 0] [0, 0, 2, 0] [0, 0, 0, 0]] PiperOrigin-RevId: 217764319
* Add support to constant dense vector/tensor attribute.Feng Liu2019-03-291-0/+153
| | | | | | | | | | | | | | | | | | | The syntax of dense vecor/tensor attribute value is `dense<` (tensor-type | vector-type)`,` attribute-list`>` and attribute-list ::= `[` attribute-list (`, ` attribute-list)* `]`. The construction of the dense vector/tensor attribute takes a vector/tensor type and a character array as arguments. The size of the input array should be larger than the size specified by the type argument. It also assumes the elements of the vector or tensor have been trunked to the data type sizes in the input character array, so it extends the trunked data to 64 bits when it is retrieved. PiperOrigin-RevId: 217762811
* Split BuiltinOps out of StandardOps.Jacques Pienaar2019-03-291-4/+3
| | | | | | | | * Move Return, Constant and AffineApply out into BuiltinOps; * BuiltinOps are always registered, while StandardOps follow the same dynamic registration; * Kept isValidX in MLValue as we don't have a verify on AffineMap so need to keep it callable from Parser (I wanted to move it to be called in verify instead); PiperOrigin-RevId: 216592527
* Simplify simplify functions as follow up on previous CL.Jacques Pienaar2019-03-291-28/+30
| | | | | | Addressing comment from post submit + simplifying the logic. PiperOrigin-RevId: 216560688
* Only simplify floor div, ceil div or mod if the rhs constant >= 1.Jacques Pienaar2019-03-291-3/+3
| | | | | | Else we hit asserts in MathExtras. PiperOrigin-RevId: 216553595
* [MLIR] IntegerSet value typeNicolas Vasilache2019-03-291-6/+10
| | | | | | | | | | | | | | | This CL applies the same pattern as AffineMap to IntegerSet: a simple struct that acts as the storage is allocated in the bump pointer. The IntegerSet is immutable and accessed everywhere by value. Note that unlike AffineMap, it is not possible to remove the MLIRContext parameter when constructing an IntegerSet for now. One possible way to achieve this would be to add an enum to distinguish between the mathematically empty set, the universe set and other sets. This is left for future discussion. PiperOrigin-RevId: 216545361
* Add support to constant splat vector/tensor attribute.Feng Liu2019-03-291-1/+19
| | | | | | | | | This attribute represents a reference to a splat vector or tensor, where all the elements have the same value. The syntax of the attribute is: `splat<` (tensor-type | vector-type)`,` attribute-value `>` PiperOrigin-RevId: 216537997
* Change the representation of an operation name to be either anChris Lattner2019-03-291-6/+0
| | | | | | | | | AbstractOperation* or an Identifier. This makes it possible to get to stuff in AbstractOperation faster than going through a hash table lookup. This makes constant folding a bit faster now, but will become more important with subsequent changes. PiperOrigin-RevId: 216476772
* Support `getShape`, `hasStaticShape` and `getDimSize` methods for all the ↵Feng Liu2019-03-291-2/+5
| | | | | | Vector and Tensor Types. PiperOrigin-RevId: 216447553
* [MLIR] AffineMap value typeNicolas Vasilache2019-03-291-21/+24
| | | | | | | | This CL applies the same pattern as AffineExpr to AffineMap: a simple struct that acts as the storage is allocated in the bump pointer. The AffineMap is immutable and accessed everywhere by value. PiperOrigin-RevId: 216445930
* [MLIR] Sketch AffineExpr value typeNicolas Vasilache2019-03-291-58/+59
| | | | | | | | | | | | | | | | This CL sketches what it takes for AffineExpr to fully have by-value semantics and not be a not-so-smart pointer anymore. This essentially makes the underyling class a simple storage struct and implements the operations on the value type directly. Since there is no forwarding of operations anymore, we can full isolate the storage class and make a hard visibility barrier by moving detail::AffineExpr into AffineExprDetail.h. AffineExprDetail.h is only included where storage-related information is needed. PiperOrigin-RevId: 216385459
* [MLIR] AffineExpr final cleanupsNicolas Vasilache2019-03-291-76/+69
| | | | | | | | | | | This CL: 1. performs the global codemod AffineXExpr->AffineXExprClass and AffineXExprRef -> AffineXExpr; 2. simplifies function calls by removing the redundant MLIRContext parameter; 3. adds missing binary operator versions of scalar op AffineExpr where it makes sense. PiperOrigin-RevId: 216242674
* [MLIR] Cleanup AffineExprNicolas Vasilache2019-03-291-18/+195
| | | | | | | | | | | | | | | | | | | | | | | | This CL introduces a series of cleanups for AffineExpr value types: 1. to make it clear that the value types should be used, the pointer AffineExpr types are put in the detail namespace. Unfortunately, since the value type operator-> only forwards to the underlying pointer type, we still need to expose this in the include file for now; 2. AffineExprKind is ok to use, it thus comes out of detail and thus of AffineExpr 3. getAffineDimExpr, getAffineSymbolExpr, getAffineConstantExpr are similarly extracted as free functions and their naming is mande consistent across Builder, MLContext and AffineExpr 4. AffineBinaryOpEx::simplify functions are made into static free functions. In particular it is moved away from AffineMap.cpp where it does not belong 5. operator AffineExprType is made explicit 6. uses the binary operators everywhere possible 7. drops the pointer usage everywhere outside of AffineExpr.cpp, MLIRContext.cpp and AsmPrinter.cpp PiperOrigin-RevId: 216207212
* [RFC][MLIR] Use AffineExprRef in place of AffineExpr* in IRNicolas Vasilache2019-03-291-17/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL starts by replacing AffineExpr* with value-type AffineExprRef in a few places in the IR. By a domino effect that is pretty telling of the inconsistencies in the codebase, const is removed where it makes sense. The rationale is that the decision was concisously made that unique'd types have pointer semantics without const specifier. This is fine but we should be consistent. In the end, the only logical invariant is that there should never be such a thing as a const AffineExpr*, const AffineMap* or const IntegerSet* in our codebase. This CL takes a number of shortcuts to killing const with fire, in particular forcing const AffineExprRef to return the underlying non-const AffineExpr*. This will be removed once AffineExpr* has disappeared in containers but for now such shortcuts allow a bit of sanity in this long quest for cleanups. The **only** places where const AffineExpr*, const AffineMap* or const IntegerSet* may still appear is by transitive needs from containers, comparison operators etc. There is still one major thing remaining here: figure out why cast/dyn_cast return me a const AffineXXX*, which in turn requires a bunch of ugly const_casts. I suspect this is due to the classof taking const AffineXXXExpr*. I wonder whether this is a side effect of 1., if it is coming from llvm itself (I'd doubt it) or something else (clattner@?) In light of this, the whole discussion about const makes total sense to me now and I would systematically apply the rule that in the end, we should never have any const XXX in our codebase for unique'd types (assuming we can remove them all in containers and no additional constness constraint is added on us from the outside world). PiperOrigin-RevId: 215811554
* [MLIR] Templated AffineExprBaseRefNicolas Vasilache2019-03-291-6/+5
| | | | | | | | | | | | | | | | | | | This CL implements AffineExprBaseRef as a templated type to allow LLVM-style casts to work properly. This also allows making AffineExprBaseRef::expr private. To achieve this, it is necessary to use llvm::simplify_type and make AffineConstExpr derive from both AffineExpr and llvm::simplify<AffineExprRef>. Note that llvm::simplify_type is just an interface to enable the proper template resolution of isa/cast/dyn_cast but it otherwise holds no value. Lastly note that certain dyn_cast operations wanted the const AffineExpr* form of AffineExprBaseRef so I made the implicit constructor take that by default and documented the immutable behavior. I think this is consistent with the decision to make unique'd type immutable by convention and never use const on them. PiperOrigin-RevId: 215642247
* [MLIR] Remove uses of AffineExpr* outside of IRNicolas Vasilache2019-03-291-8/+9
| | | | | | | | | | | | | This CL uniformizes the uses of AffineExprWrap outside of IR. The public API of AffineExpr builder is modified to only use AffineExprWrap. A few places access AffineExprWrap.expr, this is only while the API is in transition to easily keep track (i.e. make expr private and let the compiler track the errors). Parser.cpp exhibits patterns that are dependent on nullptr values so converting it is left for another CL. PiperOrigin-RevId: 215642005
* [MLIR] AffineExpr lightweight value type for operatorsNicolas Vasilache2019-03-291-6/+5
| | | | | | | | | | | | | | | | | | | | | This CL proposes adding MLIRContext* to AffineExpr as discussed previously. This allows the value class to not require the context in its constructor and makes it a POD that it makes sense to pass by value everywhere. A list of other RFC CLs will build on this. The RFC CLs are small incremental pushes of the API which would be a pretty big change otherwise. Pushing the thinking a little bit more it seems reasonable to use implicit cast/constructor to/from AffineExpr*. As this thing evolves, it looks to me like IR (and probably Parser, for not so good reasons) want to operate on AffineExpr* and the rest of the code wants to operate on the value type. For this reason I think AffineExprImpl*/AffineExpr may also make sense but I do not have a particular naming preference. The jury is still out for naming decision between the above and AffineExprBase*/AffineExpr or AffineExpr*/AffineExprRef. PiperOrigin-RevId: 215641596
* Add op registry for registering MLIR ops.Jacques Pienaar2019-03-291-1/+4
| | | | | | Instead of linking in different initializeMLIRContext functions, add a registry mechanism and function to initialize all registered ops in a given MLIRContext. Initialize all registered ops along with the StandardOps when constructing a MLIRContext. PiperOrigin-RevId: 214073842
* rework the custom op verifier hooks to use the diagnostic emissionChris Lattner2019-03-291-2/+0
| | | | | | | | | | infrastructure, instead of returning a const char*. This allows custom formatting and more interesting diagnostics. This patch regresses the error message quality from the control flow lowering pass, I'll address this in a subsequent patch. PiperOrigin-RevId: 212210681
* Continue revising diagnostic handling to simplify and generalize it, and ↵Chris Lattner2019-03-291-3/+9
| | | | | | | | | | | | | | | | | | | improve related infra. - Add a new -verify mode to the mlir-opt tool that allows writing test cases for optimization and other passes that produce diagnostics. - Refactor existing the -check-parser-errors flag to mlir-opt into a new -split-input-file option which is orthogonal to -verify. - Eliminate the special error hook the parser maintained and use the standard MLIRContext's one instead. - Enhance the default MLIRContext error reporter to print file/line/col of errors when it is available. - Add new createChecked() methods to the builder that create ops and invoke the verify hook on them, use this to detected unhandled code in the RaiseControlFlow pass. - Teach mlir-opt about expected-error @+, it previously only worked with @- PiperOrigin-RevId: 211305770
* Introduce a new Location abstraction to represent location data in a structuredChris Lattner2019-03-291-6/+55
| | | | | | | | (and more useful) way rather than hacking up a pile of attributes for it. In the future this will grow to represent inlined locations, fusion cases etc, but for now we start with simple Unknown and File/Line/Col locations. NFC. PiperOrigin-RevId: 210485775
* Introduce a new extract_element operation that does what it says. Introduce aChris Lattner2019-03-291-11/+0
| | | | | | | | | | new VectorOrTensorType class that provides a common interface between vector and tensor since a number of operations will be uniform across them (including extract_element). Improve the LoadOp verifier. I also updated the MLIR spec doc as well. PiperOrigin-RevId: 209953189
* Implement call and call_indirect ops.Chris Lattner2019-03-291-3/+7
| | | | | | This also fixes an infinite recursion in VariadicOperands that this turned up. PiperOrigin-RevId: 209692932
* Finish support for function attributes, and improve lots of things:Chris Lattner2019-03-291-1/+14
| | | | | | | | | | | | | | | | | | | | | | | - Have the parser rewrite forward references to their resolved values at the end of parsing. - Implement verifier support for detecting malformed function attrs. - Add efficient query for (in general, recursive) attributes to tell if they contain a function. As part of this, improve other general infrastructure: - Implement support for verifying OperationStmt's in ml functions, refactoring and generalizing support for operations in the verifier. - Refactor location handling code in mlir-opt to have the non-error expecting form of mlir-opt invocations to report error locations precisely. - Fix parser to detect verifier failures and report them through errorReporter instead of printing the error and crashing. This regresses the location info for verifier errors in the parser that were previously ascribed to the function. This will get resolved in future patches by adding support for function attributes, which we can use to manage location information. PiperOrigin-RevId: 209600980
* Implement initial support for function attributes, including parser, printer,Chris Lattner2019-03-291-0/+30
| | | | | | | | | | resolver support. Still TODO are verifier support (to make sure you don't use an attribute for a function in another module) and the TODO in ModuleParser::finalizeModule that I will handle in the next patch. PiperOrigin-RevId: 209361648
OpenPOWER on IntegriCloud