summaryrefslogtreecommitdiffstats
path: root/mlir/lib/Transforms/Vectorize.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [mlir] NFC: Remove Value::operator* and Value::operator-> now that Value is ↵River Riddle2020-01-111-13/+10
| | | | | | | | | | properly value-typed. Summary: These were temporary methods used to simplify the transition. Reviewed By: antiagainst Differential Revision: https://reviews.llvm.org/D72548
* NFC: Replace ValuePtr with Value and remove it now that Value is value-typed.River Riddle2019-12-231-13/+12
| | | | | | ValuePtr was a temporary typedef during the transition to a value-typed Value. PiperOrigin-RevId: 286945714
* Adjust License.txt file to use the LLVM licenseMehdi Amini2019-12-231-13/+4
| | | | PiperOrigin-RevId: 286906740
* NFC: Introduce new ValuePtr/ValueRef typedefs to simplify the transition to ↵River Riddle2019-12-221-20/+20
| | | | | | | | | | Value being value-typed. This is an initial step to refactoring the representation of OpResult as proposed in: https://groups.google.com/a/tensorflow.org/g/mlir/c/XXzzKhqqF_0/m/v6bKb08WCgAJ This change will make it much simpler to incrementally transition all of the existing code to use value-typed semantics. PiperOrigin-RevId: 286844725
* NFC: Remove unnecessary 'llvm::' prefix from uses of llvm symbols declared ↵River Riddle2019-12-181-7/+7
| | | | | | | | in `mlir` namespace. Aside from being cleaner, this also makes the codebase more consistent. PiperOrigin-RevId: 286206974
* Update the builder API to take ValueRange instead of ArrayRef<Value *>River Riddle2019-12-071-7/+5
| | | | | | This allows for users to provide operand_range and result_range in builder.create<> calls, instead of requiring an explicit copy into a separate data structure like SmallVector/std::vector. PiperOrigin-RevId: 284360710
* fix examples in commentsAlexandre E. Eichenberger2019-12-061-20/+18
| | | | | | | Closes tensorflow/mlir#301 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/301 from AlexandreEichenberger:vect-doc-update 7e5418a9101a4bdad2357882fe660b02bba8bd01 PiperOrigin-RevId: 284202462
* Refactor dependencies to expose Vector transformations as patterns - NFCNicolas Vasilache2019-12-031-3/+11
| | | | | | | | | This CL refactors some of the MLIR vector dependencies to allow decoupling VectorOps, vector analysis, vector transformations and vector conversions from each other. This makes the system more modular and allows extracting VectorToVector into VectorTransforms that do not depend on vector conversions. This refactoring exhibited a bunch of cyclic library dependencies that have been cleaned up. PiperOrigin-RevId: 283660308
* Unify vector op names with other dialects.Jean-Michel Gorius2019-11-221-4/+4
| | | | | | | | | | Change vector op names from VectorFooOp to Vector_FooOp and from vector::VectorFooOp to vector::FooOp. Closes tensorflow/mlir#257 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/257 from Kayjukh:master dfc3a0e04114885aaec8740d5951d6984d6e1577 PiperOrigin-RevId: 281967461
* Move VectorOps to Tablegen - (almost) NFCNicolas Vasilache2019-11-141-2/+12
| | | | | | | | | | | | | | | | This CL moves VectorOps to Tablegen and cleans up the implementation. This is almost NFC but 2 changes occur: 1. an interface change occurs in the padding value specification in vector_transfer_read: the value becomes non-optional. As a shortcut we currently use %f0 for all paddings. This should become an OpInterface for vectorization in the future. 2. the return type of vector.type_cast is trivial and simplified to `memref<vector<...>>` Relevant roundtrip and invalid tests that used to sit in core are moved to the vector dialect. The op documentation is moved to the .td file. PiperOrigin-RevId: 280430869
* Fix minor spelling tweaks (NFC)Kazuaki Ishizaki2019-10-201-6/+6
| | | | | | Closes tensorflow/mlir#177 PiperOrigin-RevId: 275692653
* NFC: Remove trivial builder get methods.River Riddle2019-10-171-1/+1
| | | | | | These don't add any value, and some are even more restrictive than the respective static 'get' method. PiperOrigin-RevId: 275391240
* Add rewrite pattern to compose maps into affine load/storesUday Bondhugula2019-09-171-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | - add canonicalization pattern to compose maps into affine loads/stores; templatize the pattern and reuse it for affine.apply as well - rename getIndices -> getMapOperands() (getIndices is confusing since these are no longer the indices themselves but operands to the map whose results are the indices). This also makes the accessor uniform across affine.apply/load/store. Change arg names on the affine load/store builder to avoid confusion. Drop an unused confusing build method on AffineStoreOp. - update incomplete doc comment for canonicalizeMapAndOperands (this was missed from a previous update). Addresses issue tensorflow/mlir#121 Signed-off-by: Uday Bondhugula <uday@polymagelabs.com> Closes tensorflow/mlir#122 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/122 from bondhugula:compose-load-store e71de1771e56a85c4282c10cb43f30cef0701c4f PiperOrigin-RevId: 269619540
* NFC: Finish replacing FunctionPassBase/ModulePassBase with OpPassBase.River Riddle2019-09-131-1/+1
| | | | | | These directives were temporary during the generalization of FunctionPass/ModulePass to OpPass. PiperOrigin-RevId: 268970259
* Refactor the 'walk' methods for operations.River Riddle2019-08-291-1/+1
| | | | | | | | | | | | This change refactors and cleans up the implementation of the operation walk methods. After this refactoring is that the explicit template parameter for the operation type is no longer needed for the explicit op walks. For example: op->walk<AffineForOp>([](AffineForOp op) { ... }); is now accomplished via: op->walk([](AffineForOp op) { ... }); PiperOrigin-RevId: 266209552
* NFC: Move AffineOps dialect to the Dialect sub-directory.River Riddle2019-08-201-1/+1
| | | | PiperOrigin-RevId: 264482571
* Move Linalg and VectorOps dialects to the Dialect subdir - NFCNicolas Vasilache2019-08-191-1/+1
| | | | PiperOrigin-RevId: 264277760
* NFC: Move LLVMIR, SDBM, and StandardOps to the Dialect/ directory.River Riddle2019-08-191-1/+1
| | | | PiperOrigin-RevId: 264193915
* Change from llvm::make_unique to std::make_uniqueJacques Pienaar2019-08-171-1/+1
| | | | | | | | 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
* Express ownership transfer in PassManager API through std::unique_ptr (NFC)Mehdi Amini2019-08-121-2/+2
| | | | | | | | | | | | | | Since raw pointers are always passed around for IR construct without implying any ownership transfer, it can be error prone to have implicit ownership transferred the same way. For example this code can seem harmless: Pass *pass = .... pm.addPass(pass); pm.addPass(pass); pm.run(module); PiperOrigin-RevId: 263053082
* Add a higher-order vector.extractelement operation in MLIRNicolas Vasilache2019-08-091-4/+4
| | | | | | | | This CL is step 2/n towards building a simple, programmable and portable vector abstraction in MLIR that can go all the way down to generating assembly vector code via LLVM's opt and llc tools. This CL adds the vector.extractelement operation to the MLIR vector dialect as well as the appropriate roundtrip test. Lowering to LLVM will occur in the following CL. PiperOrigin-RevId: 262545089
* Fix clang 5.0 by using type aliases for LLVM DenseSet/MapMehdi Amini2019-08-031-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | When inlining the declaration for llvm::DenseSet/DenseMap in the mlir namespace from a forward declaration, clang does not take the default for the template parameters if their are declared later. namespace llvm { template<typename Foo> class DenseMap; } namespace mlir { using llvm::DenseMap; } namespace llvm { template<typename Foo = int> class DenseMap {}; } namespace mlir { DenseMap<> map; } PiperOrigin-RevId: 261495612
* NFC: Rename Function to FuncOp.River Riddle2019-07-101-1/+1
| | | | PiperOrigin-RevId: 257293379
* Globally change load/store/dma_start/dma_wait operations over to ↵Andy Davis2019-07-031-24/+59
| | | | | | | | | | | affine.load/store/dma_start/dma_wait. In most places, this is just a name change (with the exception of affine.dma_start swapping the operand positions of its tag memref and num_elements operands). Significant code changes occur here: *) Vectorization: LoopAnalysis.cpp, Vectorize.cpp *) Affine Transforms: Transforms/Utils/Utils.cpp PiperOrigin-RevId: 256395088
* NFC: Refactor Function to be value typed.River Riddle2019-07-011-2/+2
| | | | | | 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
* NFC: Remove the 'context' parameter from OperationState.River Riddle2019-06-221-5/+4
| | | | | | Now that Locations are Attributes they contain a direct reference to the MLIRContext, i.e. the context can be directly accessed from the given location instead of being explicitly passed in. PiperOrigin-RevId: 254568329
* Refactor SplatElementsAttr to inherit from DenseElementsAttr as opposed to ↵River Riddle2019-06-191-9/+9
| | | | | | being a separate Attribute type. DenseElementsAttr provides a better internal representation for splat values as well as better API for accessing elements. PiperOrigin-RevId: 253138287
* NFC: Rename FuncBuilder to OpBuilder and refactor to take a top level region ↵River Riddle2019-06-091-5/+5
| | | | | | instead of a function. PiperOrigin-RevId: 251563898
* Fix 5 ClangTidy - Readability findings.Jacques Pienaar2019-06-011-2/+0
| | | | | | | | | | | | * the 'empty' method should be used to check for emptiness instead of 'size' * using decl 'CapturableHandle' is unused * redundant get() call on smart pointer * using decl 'apply' is unused * using decl 'ScopeGuard' is unused -- PiperOrigin-RevId: 250623863
* Remove unnecessary C++ specifier in CPP files. NFC.Jacques Pienaar2019-05-201-1/+1
| | | | | | | | These are only required in .h files to disambiguate between C and C++ header files. -- PiperOrigin-RevId: 248219135
* Replace Operation::isa with llvm::isa.River Riddle2019-05-201-6/+6
| | | | | | -- PiperOrigin-RevId: 247789235
* Replace Operation::cast with llvm::cast.River Riddle2019-05-201-4/+4
| | | | | | -- PiperOrigin-RevId: 247785983
* Add support for using llvm::dyn_cast/cast/isa for operation casts and ↵River Riddle2019-05-201-4/+4
| | | | | | | | replace usages of Operation::dyn_cast with llvm::dyn_cast. -- PiperOrigin-RevId: 247780086
* Automated rollback of changelist 247778391.MLIR Team2019-05-201-4/+4
| | | | PiperOrigin-RevId: 247778691
* Add support for using llvm::dyn_cast/cast/isa for operation casts and ↵River Riddle2019-05-201-4/+4
| | | | | | | | replace usages of Operation::dyn_cast with llvm::dyn_cast. -- PiperOrigin-RevId: 247778391
* Remove unused Vectorize constructor (NFC)Mehdi Amini2019-05-101-11/+0
| | | | | | | | Fix gcc warning. -- PiperOrigin-RevId: 247647114
* Prepend an "affine-" prefix to Affine pass option names - NFCNicolas Vasilache2019-05-061-1/+1
| | | | | | | | | | | Trying to activate both LLVM and MLIR passes in mlir-cpu-runner showed name collisions when registering pass names. One possible way of disambiguating that should also work across dialects is to prepend the dialect name to the passes that specifically operate on that dialect. With this CL, mlir-cpu-runner tests still run when both LLVM and MLIR passes are registered -- PiperOrigin-RevId: 246539917
* Add support for basic remark diagnostics. This is the minimal ↵River Riddle2019-05-061-4/+3
| | | | | | | | functionality needed to separate notes from remarks. It also provides a starting point to start building out better remark infrastructure. -- PiperOrigin-RevId: 246175216
* Fix a few warnings for missing parentheses around '||' and extra semicolons.River Riddle2019-04-051-1/+1
| | | | | | -- PiperOrigin-RevId: 241994767
* Remove the non-postorder walk functions from Function/Block/Instruction ↵River Riddle2019-04-051-6/+3
| | | | | | | | and rename walkPostOrder to walk. -- PiperOrigin-RevId: 241965239
* Cleanup SuperVectorization dialect printing and parsing.Nicolas Vasilache2019-03-291-48/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | On the read side, ``` %3 = vector_transfer_read %arg0, %i2, %i1, %i0 {permutation_map: (d0, d1, d2)->(d2, d0)} : (memref<?x?x?xf32>, index, index, index) -> vector<32x256xf32> ``` becomes: ``` %3 = vector_transfer_read %arg0[%i2, %i1, %i0] {permutation_map: (d0, d1, d2)->(d2, d0)} : memref<?x?x?xf32>, vector<32x256xf32> ``` On the write side, ``` vector_transfer_write %0, %arg0, %c3, %c3 {permutation_map: (d0, d1)->(d0)} : vector<128xf32>, memref<?x?xf32>, index, index ``` becomes ``` vector_transfer_write %0, %arg0[%c3, %c3] {permutation_map: (d0, d1)->(d0)} : vector<128xf32>, memref<?x?xf32> ``` Documentation will be cleaned up in a followup commit that also extracts a proper .md from the top of the file comments. PiperOrigin-RevId: 241021879
* Make createMaterializeVectorsPass take a vectorSize parameter - NFCNicolas Vasilache2019-03-291-6/+4
| | | | | | | This CL allows the programmatic control of the target hardware vector size when creating a MaterializeVectorsPass. This is useful for registering passes for the tutorial. PiperOrigin-RevId: 240996136
* Refactor vectorization patternsNicolas Vasilache2019-03-291-119/+93
| | | | | | | | | | This CL removes the reliance of the vectorize pass on the specification of a `fastestVaryingDim` parameter. This parameter is a restriction meant to more easily target a particular loop/memref combination for vectorization and is mainly used for testing. This also had the side-effect of restricting vectorization patterns to only the ones in which all memrefs were contiguous along the same loop dimension. This simple restriction prevented matmul to vectorize in 2-D. this CL removes the restriction and adds the matmul test which vectorizes in 2-D along the parallel loops. Support for reduction loops is left for future work. PiperOrigin-RevId: 240993827
* Make vectorization aware of loop semanticsNicolas Vasilache2019-03-291-34/+56
| | | | | | Now that we have a dependence analysis, we can check that loops are indeed parallel and make vectorization correct. PiperOrigin-RevId: 240682727
* Give the Vectorize pass a virtualVectorSize argument.Nicolas Vasilache2019-03-291-4/+24
| | | | | | | This CL allows vectorization to be called and configured in other ways than just via command line arguments. This allows triggering vectorization programmatically. PiperOrigin-RevId: 240638208
* Replace usages of Instruction with Operation in the Transforms/ directory.River Riddle2019-03-291-66/+60
| | | | PiperOrigin-RevId: 240636130
* Replace usages of Instruction with Operation in the /Analysis directory.River Riddle2019-03-291-5/+5
| | | | PiperOrigin-RevId: 240569775
* Replace usages of Instruction with Operation in the /IR directory.River Riddle2019-03-291-8/+8
| | | | | | This is step 2/N to renaming Instruction to Operation. PiperOrigin-RevId: 240459216
* Allow creating standalone RegionsAlex Zinenko2019-03-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, regions can only be constructed by passing in a `Function` or an `Instruction` pointer referencing the parent object, unlike `Function`s or `Instruction`s themselves that can be created without a parent. It leads to a rather complex flow in operation construction where one has to create the operation first before being able to work with its regions. It may be necessary to work with the regions before the operation is created. In particular, in `build` and `parse` functions that are executed _before_ the operation is created in cases where boilerplate region manipulation is required (for example, inserting the hypothetical default terminator in affine regions). Allow creating standalone regions. Such regions are meant to own a list of blocks and transfer them to other regions on demand. Each instruction stores a fixed number of regions as trailing objects and has ownership of them. This decreases the size of the Instruction object for the common case of instructions without regions. Keep this behavior intact. To allow some flexibility in construction, make OperationState store an owning vector of regions. When the Builder creates an Instruction from OperationState, the bodies of the regions are transferred into the instruction-owned regions to minimize copying. Thus, it becomes possible to fill standalone regions with blocks and move them to an operation when it is constructed, or move blocks from a region to an operation region, e.g., for inlining. PiperOrigin-RevId: 240368183
* Make FunctionPass::getFunction() return a reference to the function, instead ofChris Lattner2019-03-291-3/+3
| | | | | | | a pointer. This makes it consistent with all the other methods in FunctionPass, as well as with ModulePass::getModule(). NFC. PiperOrigin-RevId: 240257910
OpenPOWER on IntegriCloud