aboutsummaryrefslogtreecommitdiff
path: root/mlir/test/Examples
AgeCommit message (Collapse)AuthorFilesLines
2022-09-20[mlir][standalone] Specify python path when configuringrkayaith1-1/+2
Specifying the python path here ensures that the python binary used matches the one used by the main MLIR tests. This is useful when cmake's automatic detection has to be overridden. Reviewed By: stellaraccident, bondhugula Differential Revision: https://reviews.llvm.org/D134251
2022-06-05[mlir] Tunnel LLVM_USE_LINKER through to the standalone example build.Stella Laurenzo2-1/+6
When building in debug mode, the link time of the standalone sample is excessive, taking upwards of a minute if using BFD. This at least allows lld to be used if the main invocation was configured that way. On my machine, this gets a standalone test that requires a relink to run in ~13s for Debug mode. This is still a lot, but better than it was. I think we may want to do something about this test: it adds a lot of latency to a normal compile/test cycle and requires a bunch of arg fiddling to exclude. I think we may end up wanting a `check-mlir-heavy` target that can be used just prior to submit, and then make `check-mlir` just run unit/lite tests. More just thoughts for the future (none of that is done here). Reviewed By: bondhugula, mehdi_amini Differential Revision: https://reviews.llvm.org/D126585
2022-04-07[mlir][CSE] Remove duplicated operations with MemRead side-effectValentin Clement3-6/+3
This patch enhances the CSE pass to deal with simple cases of duplicated operations with MemoryEffects. It allows the CSE pass to remove safely duplicate operations with the MemoryEffects::Read that have no other side-effecting operations in between. Other MemoryEffects::Read operation are allowed. The use case is pretty simple so far so we can build on top of it to add more features. This patch is also meant to avoid a dedicated CSE pass in FIR and was brought together afetr discussion on https://reviews.llvm.org/D112711. It does not currently cover the full range of use cases described in https://reviews.llvm.org/D112711 but the idea is to gradually enhance the MLIR CSE pass to handle common use cases that can be used by other dialects. This patch takes advantage of the new CSE capabilities in Fir. Reviewed By: mehdi_amini, rriddle, schweitz Differential Revision: https://reviews.llvm.org/D122801
2022-03-15[mlir][toy] Define a FuncOp operation in toy and drop the dependence on FuncOpRiver Riddle38-61/+61
FuncOp is being moved out of the builtin dialect, and defining a custom toy operation showcases various aspects of defining function-like operation (e.g. inlining, passes, etc.). Differential Revision: https://reviews.llvm.org/D121264
2021-11-14Re-apply "[mlir] Allow out-of-tree python building from installed MLIR."Stella Laurenzo2-3/+6
Re-applies D111513: * Adds a full-fledged Python example dialect and tests to the Standalone example (need to do a bit of tweaking in the top level CMake and lit tests to adapt better to if not building with Python enabled). * Rips out remnants of custom extension building in favor of pybind11_add_module which does the right thing. * Makes python and extension sources installable (outputs to src/python/${name} in the install tree): Both Python and C++ extension sources get installed as downstreams need all of this in order to build a derived version of the API. * Exports sources targets (with our properties that make everything work) by converting them to INTERFACE libraries (which have export support), as recommended for the forseeable future by CMake devs. Renames custom properties to start with lower-case letter, as also recommended/required (groan). * Adds a ROOT_DIR argument to declare_mlir_python_extension since now all C++ sources for an extension must be under the same directory (to line up at install time). * Downstreams will need to adapt by: * Remove absolute paths from any SOURCES for declare_mlir_python_extension (I believe all downstreams are just using ${CMAKE_CURRENT_SOURCE_DIR} here, which can just be ommitted). May need to set ROOT_DIR if not relative to the current source directory. * To allow further downstreams to install/build, will need to make sure that all C++ extension headers are also listed under SOURCES for declare_mlir_python_extension. This reverts commit 1a6c26d1f52999edbfbf6a978ae3f0e6759ea755. Reviewed By: stephenneuendorffer Differential Revision: https://reviews.llvm.org/D113732
2021-11-12Revert "[mlir] Allow out-of-tree python building from installed MLIR."Mehdi Amini1-3/+1
This reverts commit c7be8b75399c727ec9e1ddc3f81510f284c65155. Build is broken (multiple buildbots)
2021-11-11[mlir] Allow out-of-tree python building from installed MLIR.Stella Laurenzo1-1/+3
* Depends on D111504, which provides the boilerplate for building aggregate shared libraries from installed MLIR. * Adds a full-fledged Python example dialect and tests to the Standalone example (need to do a bit of tweaking in the top level CMake and lit tests to adapt better to if not building with Python enabled). * Rips out remnants of custom extension building in favor of `pybind11_add_module` which does the right thing. * Makes python and extension sources installable (outputs to src/python/${name} in the install tree): Both Python and C++ extension sources get installed as downstreams need all of this in order to build a derived version of the API. * Exports sources targets (with our properties that make everything work) by converting them to INTERFACE libraries (which have export support), as recommended for the forseeable future by CMake devs. Renames custom properties to start with lower-case letter, as also recommended/required (groan). * Adds a ROOT_DIR argument to `declare_mlir_python_extension` since now all C++ sources for an extension must be under the same directory (to line up at install time). * Need to validate against a downstream or two and adjust, prior to submitting. Downstreams will need to adapt by: * Remove absolute paths from any SOURCES for `declare_mlir_python_extension` (I believe all downstreams are just using `${CMAKE_CURRENT_SOURCE_DIR}` here, which can just be ommitted). May need to set `ROOT_DIR` if not relative to the current source directory. * To allow further downstreams to install/build, will need to make sure that all C++ extension headers are also listed under SOURCES for `declare_mlir_python_extension`. Reviewed By: stephenneuendorffer, mikeurbach Differential Revision: https://reviews.llvm.org/D111513
2021-10-13[mlir] Ability to build CAPI dylibs from out of tree projects against ↵Stella Laurenzo1-1/+1
installed LLVM. * Incorporates a reworked version of D106419 (which I have closed but has comments on it). * Extends the standalone example to include a minimal CAPI (for registering its dialect) and a test which, from out of tree, creates an aggregate dylib and links a little sample program against it. This will likely only work today in *static* MLIR builds (until the TypeID fiasco is finally put to bed). It should work on all platforms, though (including Windows - albeit I haven't tried this exact incarnation there). * This is the biggest pre-requisite to being able to build out of tree MLIR Python-based projects from an installed MLIR/LLVM. * I am rather nauseated by the CMake shenanigans I had to endure to get this working. The primary complexity, above and beyond the previous patch is because (with no reason given), it is impossible to export target properties that contain generator expressions... because, of course it isn't. In this case, the primary reason we use generator expressions on the individual embedded libraries is to support arbitrary ordering. Since that need doesn't apply to out of tree (which import everything via FindPackage at the outset), we fall back to a more imperative way of doing the same thing if we detect that the target was imported. Gross, but I don't expect it to need a lot of maintenance. * There should be a relatively straight-forward path from here to rebase libMLIR.so on top of this facility and also make it include the CAPI. Differential Revision: https://reviews.llvm.org/D111504
2021-10-13[MLIR] Replace std ops with arith dialect opsMogball3-42/+42
Precursor: https://reviews.llvm.org/D110200 Removed redundant ops from the standard dialect that were moved to the `arith` or `math` dialects. Renamed all instances of operations in the codebase and in tests. Reviewed By: rriddle, jpienaar Differential Revision: https://reviews.llvm.org/D110797
2021-10-02Fix/disable more MLIR tests exposing leaks in ASAN builds (NFC)Mehdi Amini1-0/+5
2021-06-02[MLIR] Fix Standalone dialect test to work in out-of-tree buildsKrzysztof Drewniak2-1/+3
When LLVM and MLIR are built as subprojects (via add_subdirectory), the CMake configuration that indicates where the MLIR libraries are is not necessarily in the same cmake/ directory as LLVM's configuration. This patch removes that assumption about where MLIRConfig.cmake is located. (As an additional none, the %llvm_lib_dir substitution was never defined, and so find_package(MLIR) in the build was succeeding for other reasons.) Reviewed By: stephenneuendorffer Differential Revision: https://reviews.llvm.org/D103276
2021-05-25[Toy] Update tests to pass with top-down canonicalize pass. NFCChris Lattner3-36/+36
2021-03-15[MLIR] Create memref dialect and move dialect-specific ops from std.Julian Gross3-30/+30
Create the memref dialect and move dialect-specific ops from std dialect to this dialect. Moved ops: AllocOp -> MemRef_AllocOp AllocaOp -> MemRef_AllocaOp AssumeAlignmentOp -> MemRef_AssumeAlignmentOp DeallocOp -> MemRef_DeallocOp DimOp -> MemRef_DimOp MemRefCastOp -> MemRef_CastOp MemRefReinterpretCastOp -> MemRef_ReinterpretCastOp GetGlobalMemRefOp -> MemRef_GetGlobalOp GlobalMemRefOp -> MemRef_GlobalOp LoadOp -> MemRef_LoadOp PrefetchOp -> MemRef_PrefetchOp ReshapeOp -> MemRef_ReshapeOp StoreOp -> MemRef_StoreOp SubViewOp -> MemRef_SubViewOp TransposeOp -> MemRef_TransposeOp TensorLoadOp -> MemRef_TensorLoadOp TensorStoreOp -> MemRef_TensorStoreOp TensorToMemRefOp -> MemRef_BufferCastOp ViewOp -> MemRef_ViewOp The roadmap to split the memref dialect from std is discussed here: https://llvm.discourse.group/t/rfc-split-the-memref-dialect-from-std/2667 Differential Revision: https://reviews.llvm.org/D98041
2021-03-08Forward the `LLVM_ENABLE_LIBCXX` CMake parameter to the mlir standalone testMehdi Amini2-1/+2
This allows to build and test MLIR with `-DLLVM_ENABLE_LIBCXX=ON`.
2021-02-19Revert "Revert "Fix MLIR Toy tutorial JIT example and add a test to cover it""Mehdi Amini2-0/+12
This reverts commit f36060417ad3e247900dfcb07a2476a9d92ee2d2 and reapply commit ae15b1e7ad71e4bfde1b031dd5e6b0bbb3b88a42. JIT test must be annotated to not run on Windows.
2021-02-19Revert "Fix MLIR Toy tutorial JIT example and add a test to cover it"Stella Stamenova2-10/+0
This reverts commit ae15b1e7ad71e4bfde1b031dd5e6b0bbb3b88a42. This commit caused failures on the mlir windows buildbot
2021-02-19Fix MLIR Toy tutorial JIT example and add a test to cover itMehdi Amini2-0/+10
2021-02-18Revert "[MLIR] Create memref dialect and move several dialect-specific ops ↵Alexander Belyaev3-30/+30
from std." This commit introduced a cyclic dependency: Memref dialect depends on Standard because it used ConstantIndexOp. Std depends on the MemRef dialect in its EDSC/Intrinsics.h Working on a fix. This reverts commit 8aa6c3765b924d86f623d452777eb76b83bf2787.
2021-02-18[MLIR] Create memref dialect and move several dialect-specific ops from std.Julian Gross3-30/+30
Create the memref dialect and move several dialect-specific ops without dependencies to other ops from std dialect to this dialect. Moved ops: AllocOp -> MemRef_AllocOp AllocaOp -> MemRef_AllocaOp DeallocOp -> MemRef_DeallocOp MemRefCastOp -> MemRef_CastOp GetGlobalMemRefOp -> MemRef_GetGlobalOp GlobalMemRefOp -> MemRef_GlobalOp PrefetchOp -> MemRef_PrefetchOp ReshapeOp -> MemRef_ReshapeOp StoreOp -> MemRef_StoreOp TransposeOp -> MemRef_TransposeOp ViewOp -> MemRef_ViewOp The roadmap to split the memref dialect from std is discussed here: https://llvm.discourse.group/t/rfc-split-the-memref-dialect-from-std/2667 Differential Revision: https://reviews.llvm.org/D96425
2020-11-09[MLIR] Change FuncOp assembly syntax to print visibility inline instead of ↵Rahul Joshi9-15/+10
in attrib dict. - Change syntax for FuncOp to be `func <visibility>? @name` instead of printing the visibility in the attribute dictionary. - Since printFunctionLikeOp() and parseFunctionLikeOp() are also used by other operations, make the "inline visibility" an opt-in feature. - Updated unit test to use and check the new syntax. Differential Revision: https://reviews.llvm.org/D90859
2020-10-04Revert "[RFC] Factor out repetitive cmake patterns for llvm-style projects"Stephen Neuendorffer1-1/+0
This reverts commit e9b87f43bde8b5f0d8a79c5884fdce639b12e0ca. There are issues with macros generating macros without an obvious simple fix so I'm going to revert this and try something different.
2020-10-03[RFC] Factor out repetitive cmake patterns for llvm-style projectsStephen Neuendorffer1-0/+1
New projects (particularly out of tree) have a tendency to hijack the existing llvm configuration options and build targets (add_llvm_library, add_llvm_tool). This can lead to some confusion. 1) When querying a configuration variable, do we care about how LLVM was configured, or how these options were configured for the out of tree project? 2) LLVM has lots of defaults, which are easy to miss (e.g. LLVM_BUILD_TOOLS=ON). These options all need to be duplicated in the CMakeLists.txt for the project. In addition, with LLVM Incubators coming online, we need better ways for these incubators to do things the "LLVM way" without alot of futzing. Ideally, this would happen in a way that eases importing into the LLVM monorepo when projects mature. This patch creates some generic infrastructure in llvm/cmake/modules and refactors MLIR to use this infrastructure. This should expand to include add_xxx_library, which is by far the most complicated bit of building a project correctly, since it has to deal with lots of shared library configuration bits. (MLIR currently hijacks the LLVM infrastructure for building libMLIR.so, so this needs to get refactored anyway.) Differential Revision: https://reviews.llvm.org/D85140
2020-06-05[lit] Improve naming of test result categoriesJulian Lettner1-1/+1
Improve consistency when printing test results: Previously we were using different labels for group names (the header for the list of, e.g., failing tests) and summary count lines. For example, "Failing Tests"/"Unexpected Failures". This commit changes lit to label things consistently. Improve wording of labels: When talking about individual test results, the first word in "Unexpected Failures", "Expected Passes", and "Individual Timeouts" is superfluous. Some labels contain the word "Tests" and some don't. Let's simplify the names. Before: ``` Failing Tests (1): ... Expected Passes : 3 Unexpected Failures: 1 ``` After: ``` Failed Tests (1): ... Passed: 3 Failed: 1 ``` Reviewed By: ldionne Differential Revision: https://reviews.llvm.org/D77708
2020-05-29[mlir] Add test to check if standalone dialect is registeredMarius Brehler1-1/+1
Summary: Add a test to check if the standalone dialect is registered within standalone-opt. Similar to the mlir-opt commandline.mlir test. Reviewers: Kayjukh, stephenneuendorffer Reviewed By: Kayjukh Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, jurahul, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80764
2020-05-28[mlir] Extend standalone example by standalone-translateMarius Brehler1-2/+2
Extend the standalone by standalone-translate, based on mlir-translate. Differential Revision: https://reviews.llvm.org/D80737
2020-05-11[MLIR] Fix several misc issues in in Toy tutorialRahul Joshi8-16/+16
Summary: - Fix comments in several places - Eliminate extra ' in AST dump and adjust tests accordingly Differential Revision: https://reviews.llvm.org/D78399
2020-05-05[MLIR] Add a tests for out of tree dialect example.Stephen Neuendorffer2-0/+7
This attempts to ensure that out of tree usage remains stable. Differential Revision: https://reviews.llvm.org/D78656
2020-04-17[MLIR] Update tutorial to add missing tests and bring directory paths and ↵Lucy Fox3-6/+6
code snippets up to date. Summary: The tests referred to in Chapter 3 of the tutorial were missing from the tutorial test directory; this adds those missing tests. This also cleans up some stale directory paths and code snippets used throughout the tutorial. Differential Revision: https://reviews.llvm.org/D76809
2020-04-17[MLIR] Update tutorial to add missing tests and bring directory paths and ↵Lucy Fox10-82/+47
code snippets up to date. Summary: The tests referred to in Chapter 3 of the tutorial were missing from the tutorial test directory; this adds those missing tests. This also cleans up some stale directory paths and code snippets used throughout the tutorial. Differential Revision: https://reviews.llvm.org/D76809
2020-04-17[MLIR] Update tutorial to add missing tests and bring directory paths and ↵Lucy Fox10-0/+205
code snippets up to date. Summary: The tests referred to in Chapter 3 of the tutorial were missing from the tutorial test directory; this adds those missing tests. This also cleans up some stale directory paths and code snippets used throughout the tutorial. Subscribers: mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, aartbik, liufengdb, Joonsoo, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D76809
2020-03-03[mlir][Tutorial] Make parsing an empty file print a better error.Matthias Kramm7-0/+22
Summary: Previously, we would, for an empty file, print the somewhat confusing Assertion `tok == curTok [...]' failed. With this change, we now print Parse error [...]: expected 'def' [...] This only affects the parser from chapters 1-6, since the more advanced chapter 7 parser is actually able to generate an empty module from an empty file. Nonetheless, this commit also adds the additional check to the chapter 7 parser, for consistency. Differential Revision: https://reviews.llvm.org/D75534
2020-02-21[mlir][Tutorial] Add a section to Toy Ch.2 detailing the custom assembly format.River Riddle23-220/+219
Summary: This details the C++ format as well as the new declarative format. This has been one of the major missing pieces from the toy tutorial. Differential Revision: https://reviews.llvm.org/D74938
2020-01-27[mlir] Replace toy::DeadFunctionEliminationPass with symbolDCEPass.River Riddle5-5/+10
Summary: The dead function elimination pass in toy was a temporary stopgap until we had proper dead function elimination support in MLIR. Now that this functionality is available, this pass is no longer necessary. Differential Revision: https://reviews.llvm.org/D72483
2019-11-27Fixed typo in Toy tutorial (second var e -> var f)Aart Bik7-14/+14
PiperOrigin-RevId: 282810649
2019-11-07Add Ch-7 of the toy tutorial detailing how to define new types.River Riddle10-0/+369
This chapter adds a new composite type to Toy, and shows the process of adding a new type to the IR, adding and updating operations to use it, and constant folding operations producing it. PiperOrigin-RevId: 279107885
2019-10-21Cleanup and rewrite Ch-4.md.River Riddle3-15/+9
This change rewrites Ch-4.md to introduced interfaces in a detailed step-by-step manner, adds examples, and fixes some errors. PiperOrigin-RevId: 275887017
2019-10-21NFC: Fix remaining usages of MulOp as matrix multiplication.River Riddle14-131/+149
MulOp now represents an element-wise multiplication instead of a matrix multiplication. PiperOrigin-RevId: 275886774
2019-10-20NFC: Fix typo : Retur -> ReturnRiver Riddle6-6/+6
PiperOrigin-RevId: 275745931
2019-10-17NFC: Delete the Linalg tutorial.River Riddle1-169/+0
This part of the tutorial is now covered by a new flow in Toy. This also removes a point of confusion as there is also a proper Linalg dialect. PiperOrigin-RevId: 275338933
2019-10-17Add Ch.6 of the Toy tutorial.River Riddle7-0/+246
This chapters introduces the notion of a full conversion, and adds support for lowering down to the LLVM dialect, LLVM IR, and thus code generation. PiperOrigin-RevId: 275337786
2019-10-16Fix invalid transpose in example and add proper verification.River Riddle1-36/+36
The transpose in the example had the same result type as its input, which is incorrect. PiperOrigin-RevId: 275186568
2019-10-16Add Ch.5 of the toy tutorial.River Riddle10-139/+174
This chapter adds a partial lowering of toy operations, all but PrintOp, to a combination of the Affine and Std dialects. This chapter focuses on introducing the conversion framework, the benefits of partial lowering, and how easily dialects may co-exist in the IR. PiperOrigin-RevId: 275150649
2019-10-16Add support for inlining toy call operations.River Riddle1-0/+30
The GenericCallOp needed to have the CallOpInterface to be picked up by the inliner. This also adds a CastOp to perform shape casts that are generated during inlining. The casts generated by the inliner will be folded away after shape inference. PiperOrigin-RevId: 275150438
2019-10-16Update Chapter 4 of the Toy tutorialSana Damani6-67/+21
This Chapter now introduces and makes use of the Interface concept in MLIR to demonstrate ShapeInference. END_PUBLIC Closes tensorflow/mlir#191 PiperOrigin-RevId: 275085151
2019-10-16Update comments in ast.toyJacques Pienaar3-84/+87
PiperOrigin-RevId: 275084969
2019-10-15Update Chapter 3 to demonstrate pattern match and rewrite optimizationsSana Damani3-23/+20
This is using Table-driven Declarative Rewrite Rules (DRR), the previous version of the tutorial only showed the C++ patterns. Closes tensorflow/mlir#187 PiperOrigin-RevId: 274852321
2019-10-14Merge Ch3 of the Toy tutorial into chapter 2.River Riddle2-5/+17
This effectively rewrites Ch.2 to introduce dialects, operations, and registration instead of deferring to Ch.3. This allows for introducing the best practices up front(using ODS, registering operations, etc.), and limits the opaque API to the chapter document instead of the code. PiperOrigin-RevId: 274724289
2019-10-11Emit LLVM IR equivalent of sizeof when lowering alloc operationsAlex Zinenko1-1/+1
Originally, the lowering of `alloc` operations has been computing the number of bytes to allocate when lowering based on the properties of MLIR type. This does not take into account type legalization that happens when compiling LLVM IR down to target assembly. This legalization can widen the type, potentially leading to out-of-bounds accesses to `alloc`ed data due to mismatches between address computation that takes the widening into account and allocation that does not. Use the LLVM IR's equivalent of `sizeof` to compute the number of bytes to be allocated: %0 = getelementptr %type* null, %indexType 0 %1 = ptrtoint %type* %0 to %indexType adapted from http://nondot.org/sabre/LLVMNotes/SizeOf-OffsetOf-VariableSizedStructs.txt PiperOrigin-RevId: 274159900
2019-09-30Normalize MemRefType lowering to LLVM as strided MemRef descriptorNicolas Vasilache1-6/+6
This CL finishes the implementation of the lowering part of the [strided memref RFC](https://groups.google.com/a/tensorflow.org/forum/#!topic/mlir/MaL8m2nXuio). Strided memrefs correspond conceptually to the following templated C++ struct: ``` template <typename Elem, size_t Rank> struct { Elem *ptr; int64_t offset; int64_t sizes[Rank]; int64_t strides[Rank]; }; ``` The linearization procedure for address calculation for strided memrefs is the same as for linalg views: `base_offset + SUM_i index_i * stride_i`. The following CL will unify Linalg and Standard by removing !linalg.view in favor of strided memrefs. PiperOrigin-RevId: 272033399
2019-09-27Remove spurious debug spew in testsNicolas Vasilache1-1/+0
PiperOrigin-RevId: 271624731
generated by cgit v1.1 at 2024-09-08 08:56:29 +0000