summaryrefslogtreecommitdiffstats
path: root/mlir/lib/Support
Commit message (Collapse)AuthorAgeFilesLines
* [mlir] Make code blocks more consistentJacques Pienaar2019-12-311-1/+1
| | | | Use the same form specification for the same type of code.
* Adjust License.txt file to use the LLVM licenseMehdi Amini2019-12-236-78/+24
| | | | PiperOrigin-RevId: 286906740
* NFC: Remove unnecessary 'llvm::' prefix from uses of llvm symbols declared ↵River Riddle2019-12-183-28/+27
| | | | | | | | in `mlir` namespace. Aside from being cleaner, this also makes the codebase more consistent. PiperOrigin-RevId: 286206974
* mlir-translate: support -verify-diagnosticsAlex Zinenko2019-11-071-21/+17
| | | | | | | | | | | MLIR translation tools can emit diagnostics and we want to be able to check if it is indeed the case in tests. Reuse the source manager error handlers provided for mlir-opt to support the verification in mlir-translate. This requires us to change the signature of the functions that are registered to translate sources to MLIR: it now takes a source manager instead of a memory buffer. PiperOrigin-RevId: 279132972
* Drop MemRefUtils from the ExecutionEngineAlex Zinenko2019-10-231-1/+0
| | | | | | | | | | The ExecutionEngine was updated recently to only take the LLVM dialect as input. Memrefs are no longer expected in the signature of the entry point function by the executor so there is no need to allocate and free them. The code in MemRefUtils is therefore dead and furthermore out of sync with the recent evolution of memref type to support strides. Drop it. PiperOrigin-RevId: 276272302
* Add missing include to llvm Allocator.hMehdi Amini2019-10-191-2/+1
| | | | | | This header is not self-contained otherwise. PiperOrigin-RevId: 275651582
* Use llvm.func to define functions with wrapped LLVM IR function typeAlex Zinenko2019-10-101-13/+5
| | | | | | | | | | | | | | This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
* Add Instance Specific Pass Options.MLIR Team2019-10-081-1/+2
| | | | | | | | | | | | | | | | This allows individual passes to define options structs and for these options to be parsed per instance of the pass while building the pass pipeline from the command line provided textual specification. The user can specify these per-instance pipeline options like so: ``` struct MyPassOptions : public PassOptions<MyPassOptions> { Option<int> exampleOption{*this, "flag-name", llvm::cl::desc("...")}; List<int> exampleListOption{*this, "list-flag-name", llvm::cl::desc("...")}; }; static PassRegistration<MyPass, MyPassOptions> pass("my-pass", "description"); ``` PiperOrigin-RevId: 273650140
* Fix JitRunner.cpp Error creation pattern and reactivate tests.Nicolas Vasilache2019-09-271-7/+13
| | | | | | | | | | linalg_integration_test.mlir and simple.mlir were temporarily disabled due to an OSS-only failure. The issue is that, once created, an llvm::Error must be explicitly checked before it can be discarded or overwritten. This CL fixes the issue and reenable the test. PiperOrigin-RevId: 271589651
* Drop support for memrefs from JitRunnerAlex Zinenko2019-09-261-104/+9
| | | | | | | | | | | | | The support for functions taking and returning memrefs of floats was introduced in the first version of the runner, created before MLIR had reliable lowering of allocation/deallocation to library calls. It forcibly runs MLIR transformation convering affine, loop and standard dialects into the LLVM dialect, unlike the other runner flows that accept the LLVM dialect directly. Memref support leads to more complex layering and is generally fragile. Drop it in favor of functions returning a scalar, or library-based function calls to print memrefs and other data structures. PiperOrigin-RevId: 271330839
* Let mlir-translate support -split-input-fileLei Zhang2019-09-233-38/+71
| | | | | | | | Similar to mlir-opt, having a -split-input-file mode is quite useful in mlir-translate. It allows to put logically related tests in the same test file for better organization. PiperOrigin-RevId: 270805467
* Add interfaces for call-like/callable operations.River Riddle2019-09-231-1/+1
| | | | | | | | | | | 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
* Support file-to-file translation in mlir-translateLei Zhang2019-09-171-1/+7
| | | | | | | | | | | | | Existing translations are either from MLIR or to MLIR. To support cases like round-tripping some external format via MLIR, one must chain two mlir-translate invocations together using pipes. This can be problematic to support -split-input-file in mlir-translate given that it won't work across pipes. Motivated by the above, this CL adds another translation category that allows file to file. This gives users more freedom. PiperOrigin-RevId: 269636438
* Change MLIR translation functions signatureLei Zhang2019-09-171-27/+22
| | | | | | | | | | This CL changes translation functions to take MemoryBuffer as input and raw_ostream as output. It is generally better to avoid handling files directly in a library (unless the library is specifically for file manipulation) and we can unify all file handling to the mlir-translate binary itself. PiperOrigin-RevId: 269625911
* Refactor pass pipeline command line parsing to support explicit pipeline ↵River Riddle2019-09-131-25/+25
| | | | | | | | | | | | | | | | 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
* Set mlir-cpu-runner JIT codegen opt level correctlyUday Bondhugula2019-09-071-16/+38
| | | | | | | | | | | | - the JIT codegen was being run at the default -O0 level; instead, propagate the opt level from the cmd line. Signed-off-by: Uday Bondhugula <uday@polymagelabs.com> Closes tensorflow/mlir#123 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/123 from bondhugula:jit-runner 3b055e47f94c9a48bf487f6400787478738cda02 PiperOrigin-RevId: 267778586
* Refactor the pass manager to support operations other than FuncOp/ModuleOp.River Riddle2019-09-022-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change generalizes the structure of the pass manager to allow arbitrary nesting pass managers for other operations, at any level. The only user visible change to existing code is the fact that a PassManager must now provide an MLIRContext on construction. A new class `OpPassManager` has been added that represents a pass manager on a specific operation type. `PassManager` will remain the top-level entry point into the pipeline, with OpPassManagers being nested underneath. OpPassManagers will still be implicitly nested if the operation type on the pass differs from the pass manager. To explicitly build a pipeline, the 'nest' methods on OpPassManager may be used: // Pass manager for the top-level module. PassManager pm(ctx); // Nest a pipeline operating on FuncOp. OpPassManager &fpm = pm.nest<FuncOp>(); fpm.addPass(...); // Nest a pipeline under the FuncOp pipeline that operates on spirv::ModuleOp OpPassManager &spvModulePM = pm.nest<spirv::ModuleOp>(); // Nest a pipeline on FuncOps inside of the spirv::ModuleOp. OpPassManager &spvFuncPM = spvModulePM.nest<FuncOp>(); To help accomplish this a new general OperationPass is added that operates on opaque Operations. This pass can be inserted in a pass manager of any type to operate on any operation opaquely. An example of this opaque OperationPass is a VerifierPass, that simply runs the verifier opaquely on the current operation. /// Pass to verify an operation and signal failure if necessary. class VerifierPass : public OperationPass<VerifierPass> { void runOnOperation() override { Operation *op = getOperation(); if (failed(verify(op))) signalPassFailure(); markAllAnalysesPreserved(); } }; PiperOrigin-RevId: 266840344
* Add missing lowering to CFG in mlir-cpu-runner + related cleanupMehdi Amini2019-09-011-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - the list of passes run by mlir-cpu-runner included -lower-affine and -lower-to-llvm but was missing -lower-to-cfg (because -lower-affine at some point used to lower straight to CFG); add -lower-to-cfg in between. IR with affine ops can now be run by mlir-cpu-runner. - update -lower-to-cfg to be consistent with other passes (create*Pass methods were changed to return unique ptrs, but -lower-to-cfg appears to have been missed). - mlir-cpu-runner was unable to parse custom form of affine op's - fix link options - drop unnecessary run options from test/mlir-cpu-runner/simple.mlir (none of the test cases had loops) - -convert-to-llvmir was changed to -lower-to-llvm at some point, but the create pass method name wasn't updated (this pass converts/lowers to LLVM dialect as opposed to LLVM IR). Fix this. (If we prefer "convert", the cmd-line options could be changed to "-convert-to-llvm/cfg" then.) Signed-off-by: Uday Bondhugula <uday@polymagelabs.com> Closes tensorflow/mlir#115 PiperOrigin-RevId: 266666909
* Add mechanism to dump JIT-compiled objects to filesJacques Pienaar2019-08-301-0/+15
| | | | | | | | | | | This commit introduces the bits to be able to dump JIT-compile objects to external files by passing an object cache to OrcJit. The new functionality is tested in mlir-cpu-runner under the flag `dump-object-file`. Closes tensorflow/mlir#95 PiperOrigin-RevId: 266439265
* Avoid assigning to an unchecked Error.River Riddle2019-08-211-10/+14
| | | | | | Fixes tensorflow/mlir#97 PiperOrigin-RevId: 264743395
* JitRunner: support entry functions returning voidAlex Zinenko2019-08-201-31/+50
| | | | | | | | | | | | | JitRunner can use as entry points functions that produce either a single '!llvm.f32' value or a list of memrefs. Memref support is legacy and was introduced before MLIR could lower memref allocation and deallocation to malloc/free calls so as to allocate the memory externally, and is likely to be dropped in the future since it unconditionally runs affine+standard-to-llvm lowering on the module instead of accepting the LLVM dialect. CUDA runner relies on memref-based flow in the runner without actually returning anything. Introduce a runner flow to use functions that return void as entry points. PiperOrigin-RevId: 264381686
* NFC: Move LLVMIR, SDBM, and StandardOps to the Dialect/ directory.River Riddle2019-08-191-1/+1
| | | | PiperOrigin-RevId: 264193915
* InitLLVM already initializes PrettyStackTraceProgramJacques Pienaar2019-08-181-2/+0
| | | | | | Remove extra PrettyStackTraceProgram and use InitLLVM consistently. PiperOrigin-RevId: 264041205
* Change from llvm::make_unique to std::make_uniqueJacques Pienaar2019-08-171-2/+2
| | | | | | | | 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
* Enable TTI for host TargetMachine in JitRunnerDiego Caballero2019-08-081-1/+13
| | | | | | | | | | | | | | This commit improves JitRunner so that it creates a target machine for the current CPU host which is used to properly initialize LLVM's TargetTransformInfo for such a target. This will enable optimizations such as vectorization in LLVM when using JitRunner. Please, note that, as part of this work, JITTargetMachineBuilder::detectHost() has been extended to include the host CPU name and sub-target features as part of the host CPU detection (https://reviews.llvm.org/D65760). Closes tensorflow/mlir#71 PiperOrigin-RevId: 262452525
* Add TTI pass initialization to pass managers.Diego Caballero2019-08-051-2/+2
| | | | | | | | | Many LLVM transformations benefits from knowing the targets. This enables optimizations, especially in a JIT context when the target is (generally) well-known. Closes tensorflow/mlir#49 PiperOrigin-RevId: 261840617
* Fully qualify DenseMap.Jacques Pienaar2019-08-021-1/+2
| | | | PiperOrigin-RevId: 261325481
* Merge TypeUtilities library into the IR libraryAlex Zinenko2019-07-202-75/+0
| | | | | | | | | | The TypeUtilities.{cpp,h}, currently living in {lib,include/mlir}/Support, do not belong to the Support library. Instead, they form a separate utility library that depends on the IR library. The operations it provides relate to standard types (tensors, memrefs) as well as to operation manipulation, making them a better fit for the main IR library. PiperOrigin-RevId: 259108314
* Add helper to get flattened tuple typesGeoffrey Martin-Noble2019-07-191-0/+6
| | | | | | The API on TupleType::getFlattenedTypes follows our normal conventions by accepting an output parameter, but requires callers to allocate their own storage and lends itself to use in an imperative style. This makes it difficult to use in tablegen. The current solution is to define a lambda that is immediately called, but it's cleaner to extract that into a helper. PiperOrigin-RevId: 258672046
* Move shared cpu runner library to Support/JitRunner.Stephan Herhut2019-07-162-0/+345
| | | | PiperOrigin-RevId: 258347825
* NFC: Rename Module to ModuleOp.River Riddle2019-07-101-1/+1
| | | | | | Module is a legacy name that only exists as a typedef of ModuleOp. PiperOrigin-RevId: 257427248
* NFC: Rename Function to FuncOp.River Riddle2019-07-101-1/+0
| | | | PiperOrigin-RevId: 257293379
* NFC: Make the 'disable-pass-threading' flag a PassManagerOption.River Riddle2019-07-081-4/+4
| | | | | | This also adds the ability to programmatically disable threading. PiperOrigin-RevId: 257051809
* Make TranslateFromMLIRFunction type return LogicalResult instead of boolAlex Zinenko2019-07-041-1/+1
| | | | | | This interface was created before MLIR introduced LogicalResult. PiperOrigin-RevId: 256554557
* NFC: Move the Function/Module/Operation::verify methods out-of-line.River Riddle2019-07-021-1/+2
| | | | | | As Functions/Modules becomes operations, these methods will conflict with the 'verify' hook already on derived operation types. PiperOrigin-RevId: 256246112
* NFC: Refactor Module to be value typed.River Riddle2019-07-022-6/+6
| | | | | | 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
* Split out TranslateClParser and add new parse method that reuses SourceMgr.Jacques Pienaar2019-06-262-0/+113
| | | | | | | | 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
* Split out mlir-opt main into separate file.Jacques Pienaar2019-06-242-0/+165
| | | | | | | | 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
* Add definition for OperandElementTypeIterator and ResultElementTypeIteratorLei Zhang2019-06-221-0/+14
| | | | | | | | | These are useful utility iterators helping use to get the element types of operands/results of shaped types. Also defined ranges for these iterators. PiperOrigin-RevId: 254180888
* Remove unnecessary StandardOps dependencyGeoffrey Martin-Noble2019-06-091-1/+1
| | | | PiperOrigin-RevId: 252032386
* Add free standing getElementTypeOrSelf member.Jacques Pienaar2019-06-092-0/+60
| | | | | | | | This function returns the element type of the underlying type or the input type itself. This removes some of the casting and code from ODS and into C++ code. I've not converted all the call sites (as this requires a new include and target) and wanted to run it past folks first. PiperOrigin-RevId: 251978156
* Remove unnecessary C++ specifier in CPP files. NFC.Jacques Pienaar2019-05-202-2/+2
| | | | | | | | These are only required in .h files to disambiguate between C and C++ header files. -- PiperOrigin-RevId: 248219135
* Refactor Attribute uniquing to use StorageUniquer instead of being hard ↵River Riddle2019-05-061-0/+26
| | | | | | | | coded in the MLIRContext. This allows for attributes to be uniqued similarly to types. This is the second step towards allowing dialects to define attributes. -- PiperOrigin-RevId: 245974705
* Refactor the generic storage object uniquing functionality from ↵River Riddle2019-05-062-0/+182
| | | | | | | | TypeUniquer into its own class 'StorageUniquer'. This is the first step in supporting dialect extensible attributes. -- PiperOrigin-RevId: 245358744
* Add build files and update README.Jacques Pienaar2019-03-301-0/+7
| | | | | | | | | * Add initial version of build files; * Update README with instructions to download and build MLIR from github; -- PiperOrigin-RevId: 241102092
* Extract openInputFile() into Support/FileUtilitiesLei Zhang2019-03-291-2/+19
| | | | | | | | | | Multiple binaries have the needs to open input files. Use this function to de-duplicate the code. Also changed openOutputFile() to return errors using std::string since it is a library call and accessing I/O in library call is not friendly. PiperOrigin-RevId: 228878221
* Create the Support library.Alex Zinenko2019-03-291-0/+39
This has been a long-standing TODO in the build system. Now that we need to share the non-inlined implementation of file utilities for translators, create a separate library for support functionality. Move Support/* headers to the new library in the build system. PiperOrigin-RevId: 222398880
OpenPOWER on IntegriCloud