summaryrefslogtreecommitdiffstats
path: root/mlir/unittests/TableGen
Commit message (Collapse)AuthorAgeFilesLines
* [mlir] Enhance classof() checks in StructsGenLei Zhang2020-01-032-3/+28
| | | | | | | | | | | Previously we only check that each field is of the correct mlir::Attribute subclass. This commit enhances to also consider the attribute's types, by leveraging the constraints already encoded in TableGen attribute definitions. Reviewed By: rsuderman Differential Revision: https://reviews.llvm.org/D72162
* Adjust License.txt file to use the LLVM licenseMehdi Amini2019-12-235-65/+20
| | | | PiperOrigin-RevId: 286906740
* minor spelling tweaksKazuaki Ishizaki2019-12-061-1/+1
| | | | | | | Closes tensorflow/mlir#290 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/290 from kiszk:spelling_tweaks_201912 9d9afd16a723dd65754a04698b3976f150a6054a PiperOrigin-RevId: 284169681
* Move BitEnumAttr from SPIRVBase.td to OpBase.tdLei Zhang2019-11-012-0/+47
| | | | | | | | | | | | | | | | | BitEnumAttr is a mechanism for modelling attributes whose value is a bitfield. It should not be scoped to the SPIR-V dialect and can be used by other dialects too. This CL is mostly shuffling code around and adding tests and docs. Functionality changes are: * Fixed to use `getZExtValue()` instead of `getSExtValue()` when getting the value from the underlying IntegerAttr for a case. * Changed to auto-detect whether there is a case whose value is all bits unset (i.e., zero). If so handle it specially in all helper methods. PiperOrigin-RevId: 277964926
* Fix minor spelling tweaks (NFC)Kazuaki Ishizaki2019-10-201-1/+1
| | | | | | Closes tensorflow/mlir#175 PiperOrigin-RevId: 275726876
* Avoid sign-compare warningJacques Pienaar2019-09-091-3/+3
| | | | PiperOrigin-RevId: 268132321
* Add missing link dependency to MLIRTableGenTestsLei Zhang2019-08-311-1/+1
| | | | PiperOrigin-RevId: 266561495
* Fix StructsGenTest.cpp CMakeFile build errorRob Suderman2019-08-301-1/+1
| | | | PiperOrigin-RevId: 266452719
* Added a TableGen generator for structured dataRob Suderman2019-08-303-0/+182
| | | | | | Similar to enum, added a generator for structured data. This provide Dictionary that stores a fixed set of values and guarantees the values are valid. It is intended to store a fixed number of values by a given name. PiperOrigin-RevId: 266437460
* [ODS] NFC: Rename EnumAttr to StrEnumAttr to be consistent with IntEnumAttrLei Zhang2019-07-021-3/+3
| | | | PiperOrigin-RevId: 256169019
* [ODS] Introduce IntEnumAttrLei Zhang2019-07-012-20/+25
| | | | | | | | | | | | | | | | | | | In ODS, right now we use StringAttrs to emulate enum attributes. It is suboptimal if the op actually can and wants to store the enum as a single integer value; we are paying extra cost on storing and comparing the attribute value. This CL introduces a new enum attribute subclass that are backed by IntegerAttr. The downside with IntegerAttr-backed enum attributes is that the assembly form now uses integer values, which is less obvious than the StringAttr-backed ones. However, that can be remedied by defining custom assembly form with the help of the conversion utility functions generated via EnumsGen. Choices are given to the dialect writers to decide which one to use for their enum attributes. PiperOrigin-RevId: 255935542
* [TableGen] Generating enum definitions and utility functionsLei Zhang2019-06-093-0/+106
| | | | | | | | | | | | | Enum attributes can be defined using `EnumAttr`, which requires all its cases to be defined with `EnumAttrCase`. To facilitate the interaction between `EnumAttr`s and their C++ consumers, add a new EnumsGen TableGen backend to generate a few common utilities, including an enum class, `llvm::DenseMapInfo` for the enum class, conversion functions from/to strings. This is controlled via the `-gen-enum-decls` and `-gen-enum-defs` command-line options of `mlir-tblgen`. PiperOrigin-RevId: 252209623
* 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-182-0/+171
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
OpenPOWER on IntegriCloud