summaryrefslogtreecommitdiffstats
path: root/mlir/unittests
Commit message (Collapse)AuthorAgeFilesLines
...
* Use TestDialect to test traits instead of unittest.Jacques Pienaar2019-06-012-132/+0
| | | | | | -- PiperOrigin-RevId: 249916947
* CMake build: force-link SDBM lib into SDBM unit testsAlex Zinenko2019-06-011-0/+1
| | | | | | | | | Otherwise, GCC < 7 does not link in the dialect registration, fails to look up the dialect in the context and cannot construct SDBM objects. -- PiperOrigin-RevId: 249259758
* Move SDBM uniquer into the SDBM dialectAlex Zinenko2019-06-011-30/+41
| | | | | | | | | | | | | | MLIRContext does not have to be aware of the SDBM unique data structures directly. Move the SDBM storage uniquer from MLIRContext to the SDBM dialect instance. Expressions that previously required a context to be constructed now require an instance of the dialect in order to access the uniquer. While they could look up the dialect in the context, it would have introduced a rather expensive lookup into each construction. Instead, the caller is expected to obtain the dialect instance and cache it. -- PiperOrigin-RevId: 249245199
* Move SDBM infrastructure into a new SDBM dialectAlex Zinenko2019-06-014-5/+12
| | | | | | | | | | | We now have sufficient extensibility in dialects to move attribute components such as SDBM out of the core IR into a dedicated dialect and make them optional. Introduce an SDBM dialect and move the code. This is a mostly non-functional change. -- PiperOrigin-RevId: 249244802
* Fix -Wsign-compare in OperationSupportTest.cppAlex Zinenko2019-06-011-5/+5
| | | | | | | | | A couple of warnings was produced when compiling this test due to comaprisons with a signed literal. Used unsigned literals instead. -- PiperOrigin-RevId: 249242970
* AffineExpr: factor uniqu'ing out of MLIRContext.cppAlex Zinenko2019-06-011-5/+5
| | | | | | | | | | | | | Affine expressions are designed as components of an attribute and are unique'd in the MLIRContext. When affine expressions were implemented, uniqu'ing objects in a context required to modify MLIRContext implementation. This is no longer the case as generic StorageUniquer has been introduced. Port the AffineExpr construction to use the new infrastructure by introducing an affineUniquer into the MLIRContext. -- PiperOrigin-RevId: 249207539
* Use FileCheck to test SDBMAlex Zinenko2019-05-201-127/+0
| | | | | | | | | | | | | SDBM has an output format representing the unterlying matrix and stripe expressions. Move the SDBM tests from unit testing framework to FileCheck-based tests, printing them to the standard output and using FileCheck to test the output. Tests that check the API proper (e.g. that SDBM expressions have a specific subtype) and that rely on non-syntatic properties (equality of the set of constraints) are not ported. -- PiperOrigin-RevId: 249006055
* Overload arithmetic operators for SDBM expressionsAlex Zinenko2019-05-201-66/+81
| | | | | | | | | | | | | | | | Provide an "unsafe" version of the overloaded arithmetic operators for SDBM expressions. These operators expect the operands to be of the right SDBM expression subtype and assert if they are not. They also perform simple folding operations as well as some semantically correct operations that construct an SDBM expression of a different subtype, e.g., a difference expression if the RHS of an operator+ is a negated variable. These operators are scoped in a namespace to allow for a future "safe" version of the operators that propagates null expressions to denote the error state when expressions have wrong subtypes. -- PiperOrigin-RevId: 248704153
* Implement SDBM and conversion between SDBM and lists of SDBMExprAlex Zinenko2019-05-201-0/+217
| | | | | | | | | | | | Implement the storage class for striped difference-bound matrices (SDBM) as a container with a difference bounds matrix and a list of stripe expressions. An SDBM defines an integer set. Provide conversion mechanisms between lists of SDBM expressions treated as equalities with zero or less-than-or-equal inequalities with zero. -- PiperOrigin-RevId: 248702871
* Don't fail verifying unranked shapes as being the same as this could be ↵Jacques Pienaar2019-05-201-4/+44
| | | | | | | | | | valid at runtime. tensor<*xf32> could be a tensor<1xf32> at runtime but this verifyShapeMatch would return failure and say function is invalid. -- PiperOrigin-RevId: 248583038
* Rename VectorOrTensorType to ShapedTypeGeoffrey Martin-Noble2019-05-201-2/+2
| | | | | | | | | | | | This is in preparation for making it also support/be a parent class of MemRefType. MemRefs have similar shape/rank/element semantics and it would be useful to be able to use these same utilities for them. This CL should not change any semantics and only change variables, types, string literals, and comments. In follow-up CLs I will prepare all callers to handle MemRef types or remove their dependence on ShapedType. Discussion/Rationale in https://groups.google.com/a/tensorflow.org/forum/#!topic/mlir/cHLoyfGu8y8 -- PiperOrigin-RevId: 248476449
* Start to introduce the "Quantizer" tool, which is responsible for ↵Stella Laurenzo2019-05-202-0/+259
| | | | | | | | | | transforming a computation expressed in floating point to one operating in terms of quantized types (where possible), either using quant-aware-training hints where available or post-training statistics. This is being integrated from an experimental side repository piece by piece over the course of several patches and will ultimately include full build support, documentation and e2e tests. -- PiperOrigin-RevId: 248259895
* Move Quantization -> Dialect/QuantOps, FxpMathOps -> Dialect/FxpMathOps.Stella Laurenzo2019-05-201-2/+2
| | | | | | | | | | | | | Adding the additional layer of directory was discussed offline and matches the Target/ tree. The names match the defacto convention we seem to be following where the C++ namespace is ^(.+)Ops/$ matched against the directory name. This is in preparation for patching the Quantizer into this tree, which would have been confusing without moving the Quantization dialect to its more proper home. It is left to others to move other dialects if desired. Tested: ninja check-mlir -- PiperOrigin-RevId: 248171982
* Use the DialectSymbolRegistry to reserve space in the Attribute::Kind ↵River Riddle2019-05-201-3/+3
| | | | | | | | enum to allow for dialects to define attribute kinds. The currently defined attributes kinds have now been moved to StandardAttributes. -- PiperOrigin-RevId: 247988373
* Add SameOperandsAndResultElementType trait.Jacques Pienaar2019-05-062-0/+92
| | | | | | | | This trait only works for tensor and vector types at the moment, verifying that the element type of an op with only tensor and vector types match. Added a unit test for it as there is no op currently in core that uses this trait. -- PiperOrigin-RevId: 246661697
* Implement the conversion between SDBMExpr and AffineExprAlex Zinenko2019-05-061-0/+61
| | | | | | | | | | | | | Since SDBM expressions are a subset of affine expressions, they can be converted to affine expressions in a straightforward way. The inverse conversion may fail when the affine expression is not an SDBM. Implement the inverse convresion assuming affine expressions are simplified and canonicalizied, detect subtractive and multiplicative forms of the stripe operation. -- PiperOrigin-RevId: 245494735
* Start building SDBM infrastructureAlex Zinenko2019-05-062-0/+183
| | | | | | | | | | | Striped difference-bound matrix expressions are a subset of affine expressions supporting low-complexity algorithms that can be useful for loop transformations. This introduces the basic data data structures for building such expressions and unique'ing them in a MLIRContext. -- PiperOrigin-RevId: 245380206
* Fix MLIRTableGenTests target_link_libraries typoLei Zhang2019-04-181-1/+1
| | | | | | -- PiperOrigin-RevId: 244168112
* [TableGen] Better support for predicate and rewrite rule specificationLei Zhang2019-04-183-0/+172
| | | | | | | | | | | | | | | | | | | | Currently predicates are written with positional placeholders `{N}` and rely on `formatv` as the engine to do substitution. The problem with this approach is that the definitions of those positional placeholders are not consistent; they are entirely up to the defining predicate of question. For example, `{0}` in various attribute constraints is used to mean the attribute, while it is used to main the builder for certain attribute transformations. This can become very confusing. This CL introduces `tgfmt` as a new mechanism to better support for predicate and rewrite rule specification. Instead of entirely relying on positional placeholders, `tgfmt` support both positional and special placeholders. The former is used for DAG operands. The latter, including $_builder, $_op, $_self, are used as special "hooks" to entities in the context. With this, the predicate and rewrite rules specification can be more consistent is more readable. -- PiperOrigin-RevId: 243249671
* Initial release of the Quantization dialectStella Laurenzo2019-04-031-0/+173
| | | | | | | | | | Includes a draft of documentation for the quantization setup. Given how many comments such docs have garnered in the past, I've biased towards a lightly edited first-draft so that people can argue about terminology, approach and structure without having spent too much time on it. Note that the sections under "Uniform quantization" were cribbed nearly verbatim from internal documentation that Daniel wrote. PiperOrigin-RevId: 241768668
* Rename the 'namePrefix' field in the Dialect class to 'name' and tidy ↵River Riddle2019-03-301-1/+1
| | | | | | | | some comments to make it clear that 'name' refers to the dialect namespace. -- PiperOrigin-RevId: 241103116
* Add build files and update README.Jacques Pienaar2019-03-304-0/+30
| | | | | | | | | * Add initial version of build files; * Update README with instructions to download and build MLIR from github; -- PiperOrigin-RevId: 241102092
* Assert that registered dialects have unique names. This creates a ↵River Riddle2019-03-291-0/+38
| | | | | | | | guarantee that the namespace of a dialect can be used a unique key. -- PiperOrigin-RevId: 241049578
* Replace remaining usages of the Instruction class with Operation.River Riddle2019-03-291-6/+6
| | | | PiperOrigin-RevId: 240777521
* Rename the Instruction class to Operation. This just renames the class, ↵River Riddle2019-03-291-26/+26
| | | | | | | | usages of Instruction will still refer to a typedef in the interim. This is step 1/N to renaming Instruction to Operation. PiperOrigin-RevId: 240431520
* Change getBroadcastedShape() to return result shape via parameterLei Zhang2019-03-291-24/+30
| | | | | | This is a more efficient way than returning SmallVector directly. PiperOrigin-RevId: 239407024
* Pull shape broadcast out as a stand-alone utility functionLei Zhang2019-03-291-0/+74
| | | | | | | | So that we can use this function to deduce broadcasted shapes elsewhere. Also added support for unknown dimensions, by following TensorFlow behavior. PiperOrigin-RevId: 237846065
* Add basic infrastructure for instrumenting pass execution and analysis ↵River Riddle2019-03-291-3/+3
| | | | | | | | | | | | computation. A virtual class, PassInstrumentation, is provided to allow for different parts of the pass manager infrastructure. The currently available hooks allow for instrumenting: * before/after pass execution * after a pass fails * before/after an analysis is computed After getting this infrastructure in place, we can start providing common developer utilities like pass timing, IR printing after pass execution, etc. PiperOrigin-RevId: 237709692
* NFC: Remove 'Result' from the analysis manager api to better reflect the ↵River Riddle2019-03-291-12/+12
| | | | | | implementation. There is no distinction between analysis computation and result. PiperOrigin-RevId: 237093101
* Add support for preserving specific analyses in the analysis manager. Passes ↵River Riddle2019-03-291-0/+112
| | | | | | | | | | | can now preserve specific analyses via 'markAnalysesPreserved'. Example: markAnalysesPreserved<DominanceInfo>(); markAnalysesPreserved<DominanceInfo, PostDominanceInfo>(); PiperOrigin-RevId: 237081454
* Add a unittests directory for MLIR and start adding tests for OperandStorage ↵River Riddle2019-03-291-0/+117
from InstructionSupport.h. PiperOrigin-RevId: 236911640
OpenPOWER on IntegriCloud