summaryrefslogtreecommitdiffstats
path: root/mlir/lib/Dialect
Commit message (Collapse)AuthorAgeFilesLines
...
* Minor spelling tweaksKazuaki Ishizaki2019-12-091-1/+1
| | | | | | Closes tensorflow/mlir#304 PiperOrigin-RevId: 284568358
* [StructuredOps][Linalg] Add a primitive pattern to rewrite the ↵Nicolas Vasilache2019-12-093-2/+102
| | | | | | | | | | | linalg.generic form of matmul to vector form. This CL uses the newly expanded matcher support to easily detect when a linalg.generic has a multiply-accumulate body. A linalg.generic with such a body is rewritten as a vector contraction. This CL additionally limits the rewrite to the case of matrix multiplication on contiguous and statically shaped memrefs for now. Before expanding further, we should harden the infrastructure for expressing custom ops with the structured ops abstraction. PiperOrigin-RevId: 284566659
* NFC: Expose constFoldBinaryOp via a headerLei Zhang2019-12-081-48/+1
| | | | | | | This allows other dialects to reuse the logic to support constant folding binary operations and reduces code duplication. PiperOrigin-RevId: 284428721
* Update the builder API to take ValueRange instead of ArrayRef<Value *>River Riddle2019-12-076-67/+49
| | | | | | 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
* Add a new ValueRange class.River Riddle2019-12-063-21/+9
| | | | | | | | This class represents a generic abstraction over the different ways to represent a range of Values: ArrayRef<Value *>, operand_range, result_range. This class will allow for removing the many instances of explicit SmallVector<Value *, N> construction. It has the same memory cost as ArrayRef, and only suffers cost from indexing(if+elsing the different underlying representations). This change only updates a few of the existing usages, with more to be changed in followups; e.g. 'build' API. PiperOrigin-RevId: 284307996
* NFC - update doc, comments, vim syntax fileUday Bondhugula2019-12-061-1/+8
| | | | | | | | | | | - for the symbol rules, the code was updated but the doc wasn't. Signed-off-by: Uday Bondhugula <uday@polymagelabs.com> Closes tensorflow/mlir#284 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/284 from bondhugula:doc 9aad8b8a715559f7ce61265f3da3f8a3c11b45ea PiperOrigin-RevId: 284283712
* Replace custom getBody method with an ODS-generated in gpu::LaunchOpAlex Zinenko2019-12-062-21/+19
| | | | PiperOrigin-RevId: 284262981
* During serialization do a walk of ops in module to find spv.module.Mahesh Ravishankar2019-12-061-4/+5
| | | | | | | | During lowering, spv.module might be within other modules (for example gpu kernel module). Walk the module op to find spirv module to serialize. PiperOrigin-RevId: 284262550
* Move GPU::LaunchOp to ODS. NFC.Alex Zinenko2019-12-061-29/+35
| | | | | | | | Move the definition of the GPU launch opreation from hand-rolled C++ code to ODS framework. This only does the moves, a follow-up is necessary to clean up users of custom functions that could be auto-generated by ODS. PiperOrigin-RevId: 284261856
* [VecOps] Rename vector.[insert|extract]element to just vector.[insert|extract]Aart Bik2019-12-061-25/+19
| | | | | | | Since these operations lower to [insert|extract][element|value] at LLVM dialect level, neither element nor value would correctly reflect the meaning. PiperOrigin-RevId: 284240727
* LLVM::GlobalOp: take address space as builder argumentAlex Zinenko2019-12-061-1/+4
| | | | | | | | | Accept the address space of the global as a builder argument when constructing an LLVM::GlobalOp instance. This decreases the reliance of LLVM::GlobalOp users on the internal name of the attribute used for this purpose. Update several uses of the address space in GPU to NVVM conversion. PiperOrigin-RevId: 284233254
* Move GPU::FuncOp definition to ODS - NFCAlex Zinenko2019-12-061-29/+30
| | | | | | | | Move the definition of the GPU function opreation from hand-rolled C++ code to ODS framework. This only does the moves, a follow-up is necessary to clean up users of custom functions that could be auto-generated by ODS. PiperOrigin-RevId: 284233245
* [VectorOps] Add lowering of vector.broadcast to LLVM IRAart Bik2019-12-061-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For example, a scalar broadcast %0 = vector.broadcast %x : f32 to vector<2xf32> return %0 : vector<2xf32> which expands scalar x into vector [x,x] by lowering to the following LLVM IR dialect to implement the duplication over the leading dimension. %0 = llvm.mlir.undef : !llvm<"<2 x float>"> %1 = llvm.mlir.constant(0 : index) : !llvm.i64 %2 = llvm.insertelement %x, %0[%1 : !llvm.i64] : !llvm<"<2 x float>"> %3 = llvm.shufflevector %2, %0 [0 : i32, 0 : i32] : !llvm<"<2 x float>">, !llvm<"<2 x float>"> return %3 : vector<2xf32> In the trailing dimensions, the operand is simply "passed through", unless a more elaborate "stretch" is required. For example %0 = vector.broadcast %arg0 : vector<1xf32> to vector<4xf32> return %0 : vector<4xf32> becomes %0 = llvm.mlir.undef : !llvm<"<4 x float>"> %1 = llvm.mlir.constant(0 : index) : !llvm.i64 %2 = llvm.extractelement %arg0[%1 : !llvm.i64] : !llvm<"<1 x float>"> %3 = llvm.mlir.constant(0 : index) : !llvm.i64 %4 = llvm.insertelement %2, %0[%3 : !llvm.i64] : !llvm<"<4 x float>"> %5 = llvm.shufflevector %4, %0 [0 : i32, 0 : i32, 0 : i32, 0 : i32] : !llvm<"<4 x float>">, !llvm<"<4 x float>"> llvm.return %5 : !llvm<"<4 x float>"> PiperOrigin-RevId: 284219926
* Unroll vector masks along with their associated vector arguments.Andy Davis2019-12-062-59/+32
| | | | | | | | | Updates vector ContractionOp to use proper vector masks (produced by CreateMaskOp/ConstantMaskOp). Leverages the following canonicalizations in unrolling unit test: CreateMaskOp -> ConstantMaskOp, StridedSliceOp(ConstantMaskOp) -> ConstantMaskOp Removes IndexTupleOp (no longer needed now that we have vector mask ops). Updates all unit tests. PiperOrigin-RevId: 284182168
* [spirv] Reorder `erase` and `emplace` to avoid "invalid iterator access".Denis Khalikov2019-12-061-1/+3
| | | | | | | | | | The iterator should be erased before adding a new entry into blockMergeInfo to avoid iterator invalidation. Closes tensorflow/mlir#299 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/299 from denis0x0D:sandbox/reoder_erase 983be565809aa0aadfc7e92962e4d4b282f63c66 PiperOrigin-RevId: 284173235
* DimOp folding for alloc/view dynamic dimensionsUday Bondhugula2019-12-061-2/+17
| | | | | | | | | Signed-off-by: Uday Bondhugula <uday@polymagelabs.com> Closes tensorflow/mlir#253 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/253 from bondhugula:dimop a4b464f24ae63fd259114558d87e11b8ee4dae86 PiperOrigin-RevId: 284169689
* minor spelling tweaksKazuaki Ishizaki2019-12-062-5/+4
| | | | | | | Closes tensorflow/mlir#290 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/290 from kiszk:spelling_tweaks_201912 9d9afd16a723dd65754a04698b3976f150a6054a PiperOrigin-RevId: 284169681
* LLVM::AddressOfOp: properly take into account the address spaceAlex Zinenko2019-12-061-1/+2
| | | | | | | | | | The AddressOf operation in the LLVM dialect return a pointer to a global variable. The latter may be in a non-default address space as indicated by the "addr_space" attribute. Check that the address space of the pointer returned by AddressOfOp matches that of the referenced GlobalOp. Update the AddressOfOp builder to respect this constraint. PiperOrigin-RevId: 284138860
* [Linalg] Add permutation information to tilingJose Ignacio Gomez2019-12-052-15/+42
| | | | | | | | | | | This patch closes issue tensorflow/mlir#271. It adds an optional permutation map to declarative tiling transformations. The map is expressed as a list of integers. Closes tensorflow/mlir#288 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/288 from tetuante:issue271 2df2938d6a1f01b3bc404ded08dea2dd1e10b588 PiperOrigin-RevId: 284064151
* Add UnrankedMemRef Typenmostafa2019-12-051-31/+55
| | | | | | | Closes tensorflow/mlir#261 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/261 from nmostafa:nmostafa/unranked 96b6e918f6ed64496f7573b2db33c0b02658ca45 PiperOrigin-RevId: 284037040
* [spirv] Add CompositeInsertOp operationDenis Khalikov2019-12-051-21/+86
| | | | | | | | | | A CompositeInsertOp operation make a copy of a composite object, while modifying one part of it. Closes tensorflow/mlir#292 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/292 from denis0x0D:sandbox/composite_insert 2200962b9057bda53cd2f2866b461e2797196380 PiperOrigin-RevId: 284036551
* Add spv.AtomicCompareExchangeWeakLei Zhang2019-12-051-0/+77
| | | | PiperOrigin-RevId: 283997917
* [spirv] Fix nested loop (de)serializationLei Zhang2019-12-052-45/+108
| | | | | | | | | | | | | | | | | | | | | | For serialization, when we have nested ops, the inner loop will create multiple SPIR-V blocks. If the outer loop has block arguments (which corresponds to OpPhi instructions), we defer the handling of OpPhi's parent block handling until we serialized all blocks and then fix it up with the result <id>. These two cases happening together was generating invalid SPIR-V blob because we previously assume the parent block to be the block containing the terminator. That is not true anymore when the block contains structured control flow ops. If that happens, it should be fixed to use the structured control flow op's merge block. For deserialization, we record a map from header blocks to their corresponding merge and continue blocks during the initial deserialization and then use the info to construct spv.selection/spv.loop. The existing implementation will also fall apart when we have nested loops. If so, we clone all blocks for the outer loop, including the ones for the inner loop, to the spv.loop's region. So the map for header blocks' merge info need to be updated; otherwise we are operating on already deleted blocks. PiperOrigin-RevId: 283949230
* Move ModuleManager functionality into mlir::SymbolTable.Tres Popp2019-12-051-10/+10
| | | | | | | | | | Note for broken code, the following transformations occurred: ModuleManager::insert(Block::iterator, Operation*) - > SymbolTable::insert(Operation*, Block::iterator) ModuleManager::lookupSymbol -> SymbolTable::lookup ModuleManager::getModule() -> SymbolTable::getOp() ModuleManager::getContext() -> SymbolTable::getOp()->getContext() ModuleManager::* -> SymbolTable::* PiperOrigin-RevId: 283944635
* Add MLIRIR as a dependency to LLVM and related dialectsLei Zhang2019-12-041-3/+3
| | | | | | Fixes tensorflow/mlir#289 PiperOrigin-RevId: 283914472
* Add emitOptional(Error|Warning|Remark) functions to simplify emission with ↵River Riddle2019-12-041-70/+29
| | | | | | | | | | | | | | | | | | an optional location. In some situations a diagnostic may optionally be emitted by the presence of a location, e.g. attribute and type verification. These situations currently require extra 'if(loc) emitError(...); return failure()' wrappers that make verification clunky. These new overloads take an optional location and a list of arguments to the diagnostic, and return a LogicalResult. We take the arguments directly and return LogicalResult instead of returning InFlightDiagnostic because we cannot create a valid diagnostic with a null location. This creates an awkward situation where a user may try to treat the, potentially null, diagnostic as a valid one and encounter crashes when attaching notes/etc. Below is an example of how these methods simplify some existing usages: Before: if (loc) emitError(*loc, "this is my diagnostic with argument: ") << 5; return failure(); After: return emitOptionalError(loc, "this is my diagnostic with argument: ", 5); PiperOrigin-RevId: 283853599
* Add canonicalization patterns for vector CreateMaskOp and StridedSliceOp to ↵Andy Davis2019-12-041-4/+158
| | | | | | | | | | | be used in the unroll vector op transformation. Adds a ConstantMaskOp to the vector ops dialect. Adds the following canonicalization patterns: CreateMaskOp -> ConstantMaskOp StridedSliceOp(ConstantMaskOp) -> ConstantMaskOp PiperOrigin-RevId: 283816752
* Drop MaterializeVectorTransfers in favor of simpler declarative unrollingNicolas Vasilache2019-12-041-13/+14
| | | | | | Now that we have unrolling as a declarative pattern, we can drop a full pass that has gone stale. In the future we may want to add specific unrolling patterns for VectorTransferReadOp. PiperOrigin-RevId: 283806880
* Adds support for unrolling single-result vector operations with iterator ↵Andy Davis2019-12-042-21/+287
| | | | | | | | type lists and indexing maps to a target vector size. Adds unit tests for unrolling the vector ContractionOp with different iteration orders. PiperOrigin-RevId: 283747503
* Refactor dependencies to expose Vector transformations as patterns - NFCNicolas Vasilache2019-12-032-0/+460
| | | | | | | | | 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
* [spirv] Add spv.GroupNonUniformBallotLei Zhang2019-12-031-0/+40
| | | | | | | | | This CL also did the following cleanup: - Moved the test for spv.SubgroupBallotKHR to its own file - Wrapped generated canonicalization patterns in anonymous namespace - Updated header comments in SPVOps.td PiperOrigin-RevId: 283650091
* Add a pass to legalize operations before lowering to SPIR-V.Mahesh Ravishankar2019-12-031-0/+36
| | | | | | | | | | | | Not all StandardOps can be lowered to SPIR-V. For example, subview op implementation requires use of pointer bitcasts which is not valid according to SPIR-V spec (or at least is ambiguous about it). Such ops need to be removed/transformed before lowering to SPIR-V. The SPIRVLegalizationPass is added a place where such legalizations can be added. Current implementation folds the subview ops with load/stores so that the lowering itself does not have to convert a subview op. PiperOrigin-RevId: 283642981
* Add CreateMaskOp to the VectorOps dialect.Andy Davis2019-12-031-0/+31
| | | | PiperOrigin-RevId: 283591888
* Convert MemRefType to a linearized array in SPIR-V lowering.Mahesh Ravishankar2019-12-031-33/+41
| | | | | | | | | | | | | | | The SPIR-V lowering used nested !spv.arrays to represented multi-dimensional arrays, with the hope that in-conjunction with the layout annotations, the shape and layout of memref can be represented directly. It is unclear though how portable this representation will end up being. It will rely on driver compilers implementing complex index computations faithfully. A more portable approach is to use linearized arrays to represent memrefs and explicitly instantiate all the index computation in SPIR-V. This gives added benefit that we can further optimize the generated code in MLIR before generating the SPIR-V binary. PiperOrigin-RevId: 283571167
* Fix ViewOp to have at most one offset operandAlex Zinenko2019-12-031-2/+8
| | | | | | | | | | | | | | | | | | | | | As described in the documentation, ViewOp is expected to take an optional dynamic offset followed by a list of dynamic sizes. However, the ViewOp parser did not include a check for the offset being a single value and accepeted a list of values instead. Furthermore, several tests have been exercising the wrong syntax of a ViewOp, passing multiple values to the dyanmic stride list, which was not caught by the parser. The trailing values could have been erronously interpreted as dynamic sizes. This is likely due to resyntaxing of the ViewOp, with the previous syntax taking the list of sizes before the offset. Update the tests to use the syntax with the offset preceding the sizes. Worse, the conversion of ViewOp to the LLVM dialect assumed the wrong order of operands with offset in the trailing position, and erronously relied on the permissive parsing that interpreted trailing dynamic offset values as leading dynamic sizes. Fix the lowering to use the correct order of operands. PiperOrigin-RevId: 283532506
* [spirv] Add spv.SubgroupBallotKHROpLei Zhang2019-12-031-3/+24
| | | | PiperOrigin-RevId: 283522284
* Add linkage support to LLVMFuncOpAlex Zinenko2019-12-031-41/+125
| | | | | | | | | A recent commit introduced the Linkage attribute to the LLVM dialect and used it in the Global Op. Also use it in LLVMFuncOp. As per LLVM Language Reference, if the linkage attribute is omitted, the function is assumed to have external linkage. PiperOrigin-RevId: 283493299
* [VectorOps] Add legality rules to broadcastAart Bik2019-12-021-3/+10
| | | | PiperOrigin-RevId: 283360101
* NFC: Update std.subview op to use AttrSizedOperandSegmentsLei Zhang2019-12-021-77/+46
| | | | | | This turns a few manually written helper methods into auto-generated ones. PiperOrigin-RevId: 283339617
* Introduce Linkage attribute to the LLVM dialectAlex Zinenko2019-12-021-7/+87
| | | | | | | | | | | LLVM IR supports linkage on global objects such as global variables and functions. Introduce the Linkage attribute into the LLVM dialect, backed by an integer storage. Use this attribute on LLVM::GlobalOp and make it mandatory. Implement parsing/printing of the attribute and conversion to LLVM IR. See tensorflow/mlir#277. PiperOrigin-RevId: 283309328
* [spirv] Check that operand of `spirv::CompositeExtractOp` is constant while ↵Denis Khalikov2019-11-281-0/+3
| | | | | | | | | folding. Closes tensorflow/mlir#281 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/281 from denis0x0D:sandbox/composite_ex_fold d02d73658bd1b9eaa515eb4e0aee34bc41d4252b PiperOrigin-RevId: 282971563
* Split out FunctionLike printing/parsing into FunctionImplementation.{h,cpp}Alex Zinenko2019-11-282-0/+2
| | | | | | | | | | | Helper utilies for parsing and printing FunctionLike Ops are only relevant to the implementation of the Op, not its definition. They depend on OpImplementation.h and increase the inclusion footprint of FunctionSupport.h, and do so only to provide some utilities in the "impl" namespace. Move them to a separate files, similarly to OpDefinition/OpImplementation distinction, and make only Op implementations use them while keeping headers cleaner. NFC. PiperOrigin-RevId: 282964556
* NFC: A few cleanups for SPIRVLoweringLei Zhang2019-11-271-51/+53
| | | | | | | Updated comments and used static instead of anonymous namspace to hide functions to be consistent with the existing codebase. PiperOrigin-RevId: 282847784
* [spirv] NFC: Add getZero() and getOne() static method to ConstantOpLei Zhang2019-11-272-2/+31
| | | | | | | Getting constant zero or one is very common so it merits a special handy method on spirv::ConstantOp itself. PiperOrigin-RevId: 282832572
* [spirv] Add folders for spv.IAdd and spv.IMulLei Zhang2019-11-271-0/+30
| | | | | | | | | Adding zero and multiplying one can be common when generating code for index calculation. This CL also sorted canonicalize.mlir to alphabetical order. PiperOrigin-RevId: 282828055
* Implement Linalg to loops lowering as a patternNicolas Vasilache2019-11-272-111/+205
| | | | | | This CL rewrites the linalg ops to loops transformations as patterns that can be targeted directly from Tablegen. Reliance on OpFolder is removed and to cope with it we introduce local folding patterns that are applied greedily. PiperOrigin-RevId: 282765550
* [VectorOps] Refine BroadcastOp in VectorOps dialectAart Bik2019-11-261-10/+8
| | | | | | | | Since second argument is always fully overwritten and shape is define in "to" clause, it is not needed. Also renamed "into" to "to" now that arg is dropped. PiperOrigin-RevId: 282686475
* [VectorOps] Add a BroadcastOp to the VectorOps dialectAart Bik2019-11-261-0/+41
| | | | PiperOrigin-RevId: 282643305
* Misc changes to lowering to SPIR-V.Mahesh Ravishankar2019-11-262-19/+65
| | | | | | | | | | | | | | | These changes to SPIR-V lowering while adding support for lowering SUbViewOp, but are not directly related. - Change the lowering of MemRefType to !spv.ptr<!spv.struct<!spv.array<...>[offset]>, ..> This is consistent with the Vulkan spec. - To enable testing a simple pattern of lowering functions is added to ConvertStandardToSPIRVPass. This is just used to convert the type of the arguments of the function. The added function lowering itself is not meant to be the way functions are eventually lowered into SPIR-V dialect. PiperOrigin-RevId: 282589644
* Relax restriction on affine_apply dim and symbol operandsNicolas Vasilache2019-11-261-5/+0
| | | | | | | | | | | | | | | | | | The affine_apply operation is currently "doubly" affine and conflates two things: 1. it applies an affine map to a list of values of type `index` that are defined as either dim or symbol 2. it restricts (and propagates constraints on) the provenance of dims and symbols to a small subset of ops for which more restrictive polyhedral constraints apply. Point 2. is related to the ability to form so-called static control parts and is related to dependence analysis and legality of transformations. Point 1. however is completely independent, the only local implication of dims and symbol for affine_apply is that dims compose while symbols concatenate as well as the structural constraint that dims may not be multiplied. The properties of composition and canonicalization in affine_apply are more generally useful. This CL relaxes the verifier on affine_apply so it can be used more generally. The relevant affine.for/if/load/store op verifiers already implement the dim and symbol checking. See this thread for the related discussion: https://groups.google.com/a/tensorflow.org/g/mlir/c/HkwCbV8D9N0/m/8srUNrX6CAAJ PiperOrigin-RevId: 282562517
OpenPOWER on IntegriCloud