summaryrefslogtreecommitdiffstats
path: root/mlir/tools
Commit message (Collapse)AuthorAgeFilesLines
...
* NFC: Refactor Module to be value typed.River Riddle2019-07-021-8/+8
| | | | | | As with Functions, Module will soon become an operation, which are value-typed. This eases the transition from Module to ModuleOp. A new class, OwningModuleRef is provided to allow for owning a reference to a Module, and will auto-delete the held module on destruction. PiperOrigin-RevId: 256196193
* NFC: Refactor Function to be value typed.River Riddle2019-07-011-9/+9
| | | | | | Move the data members out of Function and into a new impl storage class 'FunctionStorage'. This allows for Function to become value typed, which will greatly simplify the transition of Function to FuncOp(given that FuncOp is also value typed). PiperOrigin-RevId: 255983022
* Also disable generating underlying value to symbol conversion declaration ↵Lei Zhang2019-07-011-3/+7
| | | | | | when there is an enumerant without explicit value PiperOrigin-RevId: 255950779
* Avoid generating underlying value to symbol conversion function if there is ↵Lei Zhang2019-07-011-0/+7
| | | | | | an enumerant without explicit value. PiperOrigin-RevId: 255945801
* [ODS] Introduce IntEnumAttrLei Zhang2019-07-012-62/+99
| | | | | | | | | | | | | | | | | | | 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
* [spirv] Move conversion passes to a new libraryLei Zhang2019-06-281-0/+1
| | | | PiperOrigin-RevId: 255648303
* Parenthesize match expression to avoid operator precedence issuesMLIR Team2019-06-271-1/+1
| | | | PiperOrigin-RevId: 255435454
* Split out TranslateClParser and add new parse method that reuses SourceMgr.Jacques Pienaar2019-06-262-108/+5
| | | | | | | | Split out class to command line parser for translate methods into standalone class. Similar to splitting up mlir-opt to reuse functionality with different initialization. PiperOrigin-RevId: 255225790
* Make GPU to CUDA transformations independent of CUDA runtime.Stephan Herhut2019-06-261-0/+5
| | | | | | | | | | | The actual transformation from PTX source to a CUDA binary is now factored out, enabling compiling and testing the transformations independently of a CUDA runtime. MLIR has still to be built with NVPTX target support for the conversions to be built and tested. PiperOrigin-RevId: 255167139
* Split test-specific passes out of mlir-optNicolas Vasilache2019-06-241-0/+2
| | | | | | Instead put their impl in test/lib and link them into mlir-test-opt PiperOrigin-RevId: 254837439
* Remove leftover change from splitting mlir-opt change.Jacques Pienaar2019-06-241-1/+0
| | | | PiperOrigin-RevId: 254767366
* Split out mlir-opt main into separate file.Jacques Pienaar2019-06-242-127/+20
| | | | | | | | Enable reusing the real mlir-opt main from unit tests and in case where additional initialization needs to happen before main is invoked (e.g., when using different command line flag libraries). PiperOrigin-RevId: 254764575
* [spirv] Basic serializer and deserializerLei Zhang2019-06-224-0/+93
| | | | | | | | | | | | | | | | This CL adds the basic SPIR-V serializer and deserializer for converting SPIR-V module into the binary format and back. Right now only an empty module with addressing model and memory model is supported; (de)serialize other components will be added gradually with subsequent CLs. The purpose of this library is to enable importing SPIR-V binary modules to run transformations on them and exporting SPIR-V modules to be consumed by execution environments. The focus is transformations, which inevitably means changes to the binary module; so it is not designed to be a general tool for investigating the SPIR-V binary module and does not guarantee roundtrip equivalence (at least for now). PiperOrigin-RevId: 254473019
* Add SPIRV Image Type according to the spec described here :Mahesh Ravishankar2019-06-191-3/+26
| | | | | | | | | | | | | https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html#OpTypeImage. Add new enums to describe Image dimensionality, Image Depth, Arrayed information, Sampling, Sampler User information, and Image format. Doesn's support the Optional Access qualifier at this stage Fix Enum generator for tblgen to add "_" at the beginning if the enum starts with a number. PiperOrigin-RevId: 254091423
* Print proper message saying variadic ops are not supported in RewriterGenLei Zhang2019-06-191-10/+17
| | | | | | | | Support for ops with variadic operands/results will come later; but right now a proper message helps to avoid deciphering confusing error messages later in the compilation stage. PiperOrigin-RevId: 254071820
* Rename -verify mlir-opt flag to -verify-expected-diagnosticsGeoffrey Martin-Noble2019-06-191-3/+3
| | | | | | This name has caused some confusion because it suggests that it's running op verification (and that this verification isn't getting run by default). PiperOrigin-RevId: 254035268
* Add lowering pass from GPU dialect operations to LLVM/NVVM intrinsics.Stephan Herhut2019-06-191-0/+1
| | | | PiperOrigin-RevId: 253551452
* Start moving conversions to {lib,include/mlir}/ConversionAlex Zinenko2019-06-193-1/+3
| | | | | | | | | | | Conversions from dialect A to dialect B depend on both A and B. Therefore, it is reasonable for them to live in a separate library that depends on both DialectA and DialectB library, and does not forces dependees of DialectA or DialectB to also link in the conversion. Create the directory layout for the conversions and move the Standard to LLVM dialect conversion as the first example. PiperOrigin-RevId: 253312252
* Disallow using NOperands/NResults when N < 2. We have special traits for the ↵River Riddle2019-06-191-1/+11
| | | | | | case of 0/1 that we explicitly check for throughout the codebase. This also fixes weird build failures in MSVC where it doesn't properly handle template type aliases. PiperOrigin-RevId: 253269936
* Convert a nest affine loops to a GPU kernelAlex Zinenko2019-06-191-0/+1
| | | | | | | | | This converts entire loops into threads/blocks. No check on the size of the block or grid, or on the validity of parallelization is performed, it is under the responsibility of the caller to strip-mine the loops and to perform the dependence analysis before calling the conversion. PiperOrigin-RevId: 253189268
* [ODG] Fix value indices in verification error messagesLei Zhang2019-06-191-18/+23
| | | | | | | we should use the dynamic index for the specific value instead of the static one for ODS-declared values. PiperOrigin-RevId: 252873052
* [ODG] Add support for private methods in class writersLei Zhang2019-06-111-10/+45
| | | | PiperOrigin-RevId: 252602093
* [ODG] Address compiler warnings of comparing signed and unsigned integer ↵Lei Zhang2019-06-111-1/+1
| | | | | | expressions PiperOrigin-RevId: 252442613
* [ODS] Support variadic operand/result verificationLei Zhang2019-06-091-33/+39
| | | | | | | | | This CL enables verification code generation for variadic operands and results. In verify(), we use fallback getter methods to access all the dynamic values belonging to one static variadic operand/result to reuse the value range calculation there. PiperOrigin-RevId: 252288219
* [ODG] Use getODSOperands() and getODSResults() to back accessorsLei Zhang2019-06-091-106/+81
| | | | | | | | | This CL added getODSOperands() and getODSResults() as fallback getter methods for getting all the dynamic values corresponding to a static operand/result (which can be variadic). It should provide a uniform way of calculating the value ranges. All named getter methods are layered on top of these methods now. PiperOrigin-RevId: 252284270
* [TableGen] Generating enum definitions and utility functionsLei Zhang2019-06-092-0/+199
| | | | | | | | | | | | | 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
* ODG: Always deference operand/result when using named arg/result.Jacques Pienaar2019-06-091-4/+6
| | | | | | Considered adding more placeholders to designate types in the replacement pattern, but convinced for now sticking to simpler approach. This should at least enable specifying constraints across operands/results/attributes and we can start getting rid of the special cases. PiperOrigin-RevId: 251564893
* Introduce OpOperandAdaptors and emit them from ODSAlex Zinenko2019-06-031-65/+185
| | | | | | | | | | | | | | | | | | | | | When manipulating generic operations, such as in dialect conversion / rewriting, it is often necessary to view a list of Values as operands to an operation without creating the operation itself. The absence of such view makes dialect conversion patterns, among others, to use magic numbers to obtain specific operands from a list of rewritten values when converting an operation. Introduce XOpOperandAdaptor classes that wrap an ArrayRef<Value *> and provide accessor functions identical to those available in XOp. This makes it possible for conversions to use these adaptors to address the operands with names rather than rely on their position in the list. The adaptors are generated from ODS together with the actual operation definitions. This is another step towards making dialect conversion patterns specific for a given operation. Illustrate the approach on conversion patterns in the standard to LLVM dialect conversion. PiperOrigin-RevId: 251232899
* Remove the newline from the mlir-opt 'split-input-file' flag marker. ↵River Riddle2019-06-011-1/+1
| | | | | | | | This fixes support for DOS style new lines(/r/n). -- PiperOrigin-RevId: 250899420
* Disable named attribute in ODG for ArgOrResultElementTypeIs as was ↵Jacques Pienaar2019-06-011-3/+1
| | | | | | | | taking address of r-value. -- PiperOrigin-RevId: 250805965
* [ODS] Support region names and constraintsLei Zhang2019-06-011-26/+60
| | | | | | | | | | | | | Similar to arguments and results, now we require region definition in ops to be specified as a DAG expression with the 'region' operator. This way we can specify the constraints for each region and optionally give the region a name. Two kinds of region constraints are added, one allowing any region, and the other requires a certain number of blocks. -- PiperOrigin-RevId: 250790211
* Allow argument and result names replacement in predicates.Jacques Pienaar2019-06-011-1/+25
| | | | | | | | | | This allow specifying $x to refer to an operand's named argument (operand or attribute) or result. Skip variadic operands/results for now pending autogenerated discussion of their accessors. This adds a new predicate, following feedback on the naming but does not remove the old one. Post feedback I'll do that, potentially in follow up. -- PiperOrigin-RevId: 250720003
* Add keywords in target_link_libraries post add_llvm_executable.Jacques Pienaar2019-06-013-3/+3
| | | | | | -- PiperOrigin-RevId: 250704528
* Replace usages of 'add_executable' with 'add_llvm_executable'.River Riddle2019-06-013-3/+3
| | | | | | -- PiperOrigin-RevId: 250691487
* [TableGen] Making printer support $cppClass substitution (similar to ↵Ben Vanik2019-06-011-1/+3
| | | | | | | | parser). -- PiperOrigin-RevId: 250534216
* [ODS] Support numRegions in Op definitionLei Zhang2019-06-011-3/+19
| | | | | | -- PiperOrigin-RevId: 250282024
* Fix correspondence between trait names in ODS and C++ class names.Jacques Pienaar2019-06-011-2/+4
| | | | | | | | Make the correspondence between the ODS and C++ side clearer. -- PiperOrigin-RevId: 250211194
* Use SourceMgrDiagnosticHandler in mlir-translate for translations from ↵Jacques Pienaar2019-06-011-50/+59
| | | | | | | | | | MLIR input. Report errors using the file and line location using SourceMgr's diagnostic reporting. Reduce some horizontal white spacing too. -- PiperOrigin-RevId: 250193646
* [spirv] Start the SPIR-V dialectLei Zhang2019-06-011-0/+1
| | | | | | | | | | | | | | | | This CL sets up the basic structure for a SPIR-V dialect: operation definition specification, dialect registration, testing, etc. A single op, FMul, is defined and tested to showcase. The SPIR-V dialect aims to be a simple proxy for the SPIR-V binary format to enable straightforward and lightweight conversion from/to the binary format. Ops in this dialect should stay as the same semantic level and try to be a mechanical mapping to the corresponding SPIR-V instructions; but they can deviate representationally to allow using MLIR mechanisms. -- PiperOrigin-RevId: 250040830
* Use fused location for rewritten ops in generated rewrites.Jacques Pienaar2019-06-011-2/+18
| | | | | | | | This does tracks the location by recording all the ops in the source pattern and using the fused location for the transformed op. Track the locations via the rewrite state which is a bit heavy weight, in follow up to change to matchAndRewrite this will be addressed (and need for extra array go away). -- PiperOrigin-RevId: 249986555
* Make scope explicit to avoid misleading-indentation warnings.Jacques Pienaar2019-06-011-2/+2
| | | | | | -- PiperOrigin-RevId: 249986537
* Add support to RewritePattern for specifying the potential operations ↵River Riddle2019-06-011-3/+26
| | | | | | | | that can be generated during a rewrite. This will enable analyses to start understanding the possible effects of applying a rewrite pattern. -- PiperOrigin-RevId: 249936309
* Fix incorrect result type inference for nested tuples & remove hacky ↵Jacques Pienaar2019-06-011-7/+3
| | | | | | | | | | const case. Builders can be further refined but wanted to address bug where the result type was used beyond the first depth. -- PiperOrigin-RevId: 249936004
* Add pattern file location to generated code to trace origin of pattern.Jacques Pienaar2019-06-011-0/+13
| | | | | | -- PiperOrigin-RevId: 249734666
* Upstream the Quantizer tool (part 4).Stella Laurenzo2019-06-011-0/+1
| | | | | | | | | | | | This adds the basic passes needed and ties them into mlir-opt. Also adds two specific unit tests that exercise them. Next step is a standalone quantizer tool and additional cleanup. Tested: ninja check-mlir -- PiperOrigin-RevId: 249167690
* [ODS] Allow dialect to specify C++ namespacesLei Zhang2019-05-201-12/+13
| | | | | | | | | | | Previously we force the C++ namespaces to be `NS` if `SomeOp` is defined as `NS_SomeOp`. This is too rigid as it does not support nested namespaces well. This CL adds a "namespace" field into the Dialect class to allow flexible namespaces. -- PiperOrigin-RevId: 249064981
* ExecutionEngine: drop PassManager integrationAlex Zinenko2019-05-201-0/+23
| | | | | | | | | | | | | | | Originally, ExecutionEngine was created before MLIR had a proper pass management infrastructure or an LLVM IR dialect (using the LLVM target directly). It has been running a bunch of lowering passes to convert the input IR from Standard+Affine dialects to LLVM IR and, later, to the LLVM IR dialect. This is no longer necessary and is even undesirable for compilation flows that perform their own conversion to the LLVM IR dialect. Drop this integration and make ExecutionEngine accept only the LLVM IR dialect. Users of the ExecutionEngine can call the relevant passes themselves. -- PiperOrigin-RevId: 249004676
* Unify the 'constantFold' and 'fold' hooks on an operation into just ↵River Riddle2019-05-201-18/+5
| | | | | | | | 'fold'. This new unified fold hook will take constant attributes as operands, and may return an existing 'Value *' or a constant 'Attribute' when folding. This removes the awkward situation where a simple canonicalization like "sub(x,x)->0" had to be written as a canonicalization pattern as opposed to a fold. -- PiperOrigin-RevId: 248582024
* Cleanup linalg integration testNicolas Vasilache2019-05-201-2/+12
| | | | | | | | | | This CL performs post-commit cleanups. It adds the ability to specify which shared libraries to load dynamically in ExecutionEngine. The linalg integration test is updated to use a shared library. Additional minor cleanups related to LLVM lowering of Linalg are also included. -- PiperOrigin-RevId: 248346589
* Move Quantization -> Dialect/QuantOps, FxpMathOps -> Dialect/FxpMathOps.Stella Laurenzo2019-05-201-1/+1
| | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud