summaryrefslogtreecommitdiffstats
path: root/mlir/lib/Dialect
Commit message (Collapse)AuthorAgeFilesLines
...
* Integer set + operands / affine if op canonicalizationUday Bondhugula2019-09-051-35/+91
| | | | | | | | | | | | | | | | | | | | | | - turn canonicalizeMapAndOperands into a template that works on both sets and maps, and use it to introduce a utility to canonicalize an affine integer set and its operands - add pattern to canonicalize affine if op's. - rename IntegerSet::getNumOperands -> IntegerSet::getNumInputs to be consistent with AffineMap - add missing accessors for IntegerSet Doesn't need extensive testing since canonicalizeSetAndOperands just reuses canonicalizeMapAndOperands' logic, and the latter is tested on affine.apply map + operands; the new method works the same way on an integer set + operands of an affine if op for example. Signed-off-by: Uday Bondhugula <uday@polymagelabs.com> Closes tensorflow/mlir#112 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/112 from bondhugula:set-canonicalize eff72f23250b96fa7d9f5caff3877440f5de2cec PiperOrigin-RevId: 267532876
* Add support for conservatively inlining Affine operations.River Riddle2019-09-051-0/+39
| | | | | | This commit defines an initial implementation of the DialectInlinerInterface for the AffineOps dialect. This change allows for affine operations to be inlined into any region that is not an affine region. Inlining into affine regions requires special handling for dimension/symbol identifiers that will be added in followups. PiperOrigin-RevId: 267467078
* [spirv] Add spv.loopLei Zhang2019-09-051-0/+137
| | | | | | | | | | | | | | | | | | | | SPIR-V can explicitly declare structured control-flow constructs using merge instructions. These explicitly declare a header block before the control flow diverges and a merge block where control flow subsequently converges. These blocks delimit constructs that must nest, and can only be entered and exited in structured ways. Instead of having a `spv.LoopMerge` op to directly model loop merge instruction for indicating the merge and continue target, we use regions to delimit the boundary of the loop: the merge target is the next op following the `spv.loop` op and the continue target is the block that has a back-edge pointing to the entry block inside the `spv.loop`'s region. This way it's easier to discover all blocks belonging to a construct and it plays nicer with the MLIR system. Updated the SPIR-V.md doc. PiperOrigin-RevId: 267431010
* Add the initial inlining infrastructure.River Riddle2019-09-051-1/+50
| | | | | | | | | | | | | | | | | | This defines a set of initial utilities for inlining a region(or a FuncOp), and defines a simple inliner pass for testing purposes. A new dialect interface is defined, DialectInlinerInterface, that allows for dialects to override hooks controlling inlining legality. The interface currently provides the following hooks, but these are just premilinary and should be changed/added to/modified as necessary: * isLegalToInline - Determine if a region can be inlined into one of this dialect, *or* if an operation of this dialect can be inlined into a given region. * shouldAnalyzeRecursively - Determine if an operation with regions should be analyzed recursively for legality. This allows for child operations to be closed off from the legality checks for operations like lambdas. * handleTerminator - Process a terminator that has been inlined. This cl adds support for inlining StandardOps, but other dialects will be added in followups as necessary. PiperOrigin-RevId: 267426759
* Make GPU kernel outlining inline constants.Stephan Herhut2019-09-041-2/+40
| | | | | | | It is generally beneficial to pass less arguments to a kernel, so cloning constants into the kernel is beneficial. PiperOrigin-RevId: 267139084
* Properly clone Linalg ops with regionsNicolas Vasilache2019-09-032-12/+12
| | | | | | This CL adds support for proper cloning of Linalg ops that have regions (i.e. the generic linalg op). This is used to properly implement tiling and fusion for such ops. Adequate tests are added. PiperOrigin-RevId: 267027176
* Add folding rule and dialect materialization hook for spv.constantLei Zhang2019-09-032-6/+41
| | | | | | | | | This will allow us to use MLIR's folding infrastructure to deduplicate SPIR-V constants. This CL also changed isValidSPIRVType in SPIRVDialect to a static method. PiperOrigin-RevId: 266984403
* Remove unused variablesAlex Torres2019-09-031-13/+7
| | | | | | | | | | Remove unused variables and attributes from BaseViewConversionHelper on mlir/lib/Dialect/Linalg/Transforms/LowerToLLVMDialect.cpp Closes tensorflow/mlir#116 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/116 from alexst07:fix-warnings 5f638e4677492cf71a9cc040eeb6b57427d32e06 PiperOrigin-RevId: 266972082
* LLVM dialect: prefix auxiliary operations with "mlir."Alex Zinenko2019-09-031-5/+6
| | | | | | | | | | Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
* Add Select operation to SPIR-V dialect.Mahesh Ravishankar2019-09-021-0/+58
| | | | | | The SelectOp models the semantics of OpSelect from SPIR-V spec. PiperOrigin-RevId: 266849559
* Add a new dialect interface for the OperationFolder `OpFolderDialectInterface`.River Riddle2019-09-013-4/+4
| | | | | | This interface will allow for providing hooks to interrop with operation folding. The first hook, 'shouldMaterializeInto', will allow for controlling which region to insert materialized constants into. The folder will generally materialize constants into the top-level isolated region, this allows for materializing into a lower level ancestor region if it is more profitable/correct. PiperOrigin-RevId: 266702972
* Add a canonicalization to erase empty AffineForOps.River Riddle2019-08-301-1/+16
| | | | | | AffineForOp themselves are pure and can be removed if there are no internal operations. PiperOrigin-RevId: 266481293
* Add spv.Branch and spv.BranchConditionalLei Zhang2019-08-301-0/+115
| | | | | | | | This CL just covers the op definition, its parsing, printing, and verification. (De)serialization is to be implemented in a subsequent CL. PiperOrigin-RevId: 266431077
* Refactor the 'walk' methods for operations.River Riddle2019-08-294-7/+6
| | | | | | | | | | | | 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
* Add tests to verify 0.0 is quantized correctlyFeng Liu2019-08-291-1/+1
| | | | | | We should consider both signed and narrow_range cases. PiperOrigin-RevId: 266167366
* Extend map canonicalization to propagate constant operandsUday Bondhugula2019-08-291-11/+23
| | | | | | | | | | | | | | | | | | | - extend canonicalizeMapAndOperands to propagate constant operands into the map's expressions (and thus drop those operands). - canonicalizeMapAndOperands previously only dropped duplicate and unused operands; however, operands that were constants were retained. This change makes IR maps/expressions generated by various utilities/passes even simpler; also makes some of the test checks more accurate and simpler -- for eg., 0' instead of symbol(%{{.*}}). Signed-off-by: Uday Bondhugula <uday@polymagelabs.com> Closes tensorflow/mlir#107 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/107 from bondhugula:canonicalize-maps c889a51486d14fbf7db489f224f881e7e1ff7d72 PiperOrigin-RevId: 266085289
* Add verification for dimension attribute on GPUDialect index operations.Stephan Herhut2019-08-281-0/+7
| | | | PiperOrigin-RevId: 266073204
* Fix the equality check of two floating point valuesFeng Liu2019-08-281-3/+5
| | | | PiperOrigin-RevId: 266022088
* Add implementation for tensor_load and tensor_store operations.Stephan Herhut2019-08-281-0/+57
| | | | | | This change adds definitions, parsing and verification for both ops. PiperOrigin-RevId: 265954051
* Add 3 additional intrinsic ops to NVVM dialect, in preparation to implement ↵MLIR Team2019-08-271-7/+48
| | | | | | block-wide reduce. PiperOrigin-RevId: 265720077
* [spirv] Fix the entry block to start with OpLabelLei Zhang2019-08-272-2/+51
| | | | | | | | Each basic block in SPIR-V must start with an OpLabel instruction. We don't support control flow yet, so this CL just makes sure that the entry block follows this rule and is valid. PiperOrigin-RevId: 265718841
* Enhance GPU To SPIR-V conversion to support builtins and load/store ops.Mahesh Ravishankar2019-08-271-1/+8
| | | | | | | | | | | | | | | | | To support a conversion of a simple load-compute-store kernel from GPU dialect to SPIR-V dialect, the conversion of operations like "gpu.block_dim", "gpu.thread_id" which allow threads to get the launch conversion is needed. In SPIR-V these are specified as global variables with builin attributes. This CL adds support to specify builtin variables in SPIR-V conversion framework. This is used to convert the relevant operations from GPU dialect to SPIR-V dialect. Also add support for conversion of load/store operation in Standard dialect to SPIR-V dialect. To simplify the conversion add a method to build a spv.AccessChain operation that automatically determines the return type based on the base pointer type and the indices provided. PiperOrigin-RevId: 265718525
* [spirv] Add Block decoration for spv.struct.Denis Khalikov2019-08-272-0/+38
| | | | | | | | Add Block decoration for top-level spv.struct. Closes tensorflow/mlir#102 PiperOrigin-RevId: 265716241
* Lower linalg.copy to LLVM dialect in the presence of transposes.Nicolas Vasilache2019-08-231-13/+63
| | | | | | | | | | Add an extra RewritePattern that does not convert types to rewrite a CopyOp that has non-identity permutations into a sequence of TransposeOp followed by a CopyOp without such permutations. This RewitePattern is made to fail in the non-permutation case so that the conversion pattern can kick in to lower to LLVM. This is an instance of A->A->B lowering where A->A is done by a RewritePattern in case_1 and A->B is done by a ConversionPatternRewriter when not(case_1). PiperOrigin-RevId: 265171380
* Lower linalg.transpose to LLVM dialectNicolas Vasilache2019-08-231-3/+112
| | | | | | | | | | | | Add a conversion pattern that transforms a linalg.transpose op into: 1. A function entry `alloca` operation to allocate a ViewDescriptor. 2. A load of the ViewDescriptor from the pointer allocated in 1. 3. Updates to the ViewDescriptor to introduce the data ptr, offset, size and stride. Size and stride are permutations of the original values. 4. A store of the resulting ViewDescriptor to the alloca'ed pointer. The linalg.transpose op is replaced by the alloca'ed pointer. PiperOrigin-RevId: 265169112
* Add a linalg.transpose opNicolas Vasilache2019-08-231-2/+35
| | | | | | | | | | | | | | A linalg.transpose op is a pure metadata operation that takes a view + permutation map and produces another view of the same underlying data, with a different reindexing. This is a pure metadata operation that does not touch the underlying data. Example: ``` %t = linalg.transpose %v (i, j) -> (j, i) : !linalg.view<?x?xf32> ``` PiperOrigin-RevId: 265139429
* Add lowering of linalg.copy to an external C++ library and a test.Nicolas Vasilache2019-08-231-8/+19
| | | | | | This CL extends support for lowering of linalg to external C++ libraries with CopyOp. Currently this can only work when the permutation maps in the copies are identity. Future support for permutations will be added later. PiperOrigin-RevId: 265093025
* [spirv] NFC: move SPIR-V control flow ops to a separate fileLei Zhang2019-08-231-7/+7
| | | | | | This CL is also purely moving code around for better file organization. PiperOrigin-RevId: 265092566
* [spirv] Add support for extension (de)serializationLei Zhang2019-08-223-2/+67
| | | | | | | Only a few important KHR extensions are registered to the SPIR-V dialect for now. PiperOrigin-RevId: 264939428
* Avoid overflow when lowering linalg.sliceNicolas Vasilache2019-08-221-20/+21
| | | | | | | | linalg.subview used to lower to a slice with a bounded range resulting in correct bounded accesses. However linalg.slice could still index out of bounds. This CL moves the bounding to linalg.slice. LLVM select and cmp ops gain a more idiomatic builder. PiperOrigin-RevId: 264897125
* [spirv] Add support for capability (de)serializationLei Zhang2019-08-223-4/+72
| | | | | | | This CL pulls in capabilities defined in the spec and adds support for (de)serialize capabilities of a spv.module. PiperOrigin-RevId: 264877413
* NFC: Fix path of LinalgLibraryOpInterfaces inc files.River Riddle2019-08-221-1/+1
| | | | PiperOrigin-RevId: 264827908
* Add support for generating operation interfaces from the ODS framework.River Riddle2019-08-211-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Operation interfaces generally require a bit of boilerplate code to connect all of the pieces together. This cl introduces mechanisms in the ODS to allow for generating operation interfaces via the 'OpInterface' class. Providing a definition of the `OpInterface` class will auto-generate the c++ classes for the interface. An `OpInterface` includes a name, for the c++ class, along with a list of interface methods. There are two types of methods that can be used with an interface, `InterfaceMethod` and `StaticInterfaceMethod`. They are both comprised of the same core components, with the distinction that `StaticInterfaceMethod` models a static method on the derived operation. An `InterfaceMethod` is comprised of the following components: * ReturnType - A string corresponding to the c++ return type of the method. * MethodName - A string corresponding to the desired name of the method. * Arguments - A dag of strings that correspond to a c++ type and variable name respectively. * MethodBody (Optional) - An optional explicit implementation of the interface method. def MyInterface : OpInterface<"MyInterface"> { let methods = [ // A simple non-static method with no inputs. InterfaceMethod<"unsigned", "foo">, // A new non-static method accepting an input argument. InterfaceMethod<"Value *", "bar", (ins "unsigned":$i)>, // Query a static property of the derived operation. StaticInterfaceMethod<"unsigned", "fooStatic">, // Provide the definition of a static interface method. // Note: `ConcreteOp` corresponds to the derived operation typename. StaticInterfaceMethod<"Operation *", "create", (ins "OpBuilder &":$builder, "Location":$loc), [{ return builder.create<ConcreteOp>(loc); }]>, // Provide a definition of the non-static method. // Note: `op` corresponds to the derived operation variable. InterfaceMethod<"unsigned", "getNumInputsAndOutputs", (ins), [{ return op.getNumInputs() + op.getNumOutputs(); }]>, ]; PiperOrigin-RevId: 264754898
* Point to spv.AccessChain when reporting spv.AccessChain errorsLei Zhang2019-08-211-2/+1
| | | | PiperOrigin-RevId: 264742130
* Remove dead getLLVMLibraryCallImplDefinition in Linalg's ↵Nicolas Vasilache2019-08-211-27/+4
| | | | | | LowerToLLVMDialect.cpp - NFC PiperOrigin-RevId: 264740014
* Remove the wrapping function in SPIR-V (de)serializationLei Zhang2019-08-212-35/+6
| | | | | | | | | Previously Module and Function are builtinn constructs in MLIR. Due to the structural requirements we must wrap the SPIR-V module inside a Function inside a Module. Now the requirement is lifted and we can remove the wrapping function! :) PiperOrigin-RevId: 264736051
* Add a hook to the OpAsmDialectInterface to allow providing a special name ↵River Riddle2019-08-211-0/+37
| | | | | | | | for the operation result. This generalizes the current special handling for constant operations(they get named 'cst'/'true'/'false'/etc.) PiperOrigin-RevId: 264723379
* [spirv] Support i1 as bool typeLei Zhang2019-08-211-8/+14
| | | | PiperOrigin-RevId: 264612014
* Materialize spv.constants at use sitesLei Zhang2019-08-211-58/+70
| | | | | | | | | | | | | | | In SPIR-V binary format, constants are placed at the module level and referenced by instructions inside functions using their result <id>s. To model this natively (using SSA values for result <id>s), it means we need to have implicit capturing functions. We will lose the ability to have function passes if going down that path. Instead, this CL changes to materialize constants at their use sites in deserialization. It's cheap to copy constants in MLIR given that attributes is uniqued to MLIRContext. By localizing constants into functions, we can preserve isolated functions. PiperOrigin-RevId: 264582532
* NFC: Move AffineOps dialect to the Dialect sub-directory.River Riddle2019-08-205-6/+1803
| | | | PiperOrigin-RevId: 264482571
* Add spv.specConstant and spv._reference_ofLei Zhang2019-08-203-165/+364
| | | | | | | | | | | | | | | | | | | | | | | | | | | Similar to global variables, specialization constants also live in the module scope and can be referenced by instructions in functions in native SPIR-V. A direct modelling would be to allow functions in the SPIR-V dialect to implicit capture, but it means we are losing the ability to write passes for Functions. While in SPIR-V normally we want to process the module as a whole, it's not common to see multiple functions get used so we'd like to leave the door open for those cases. Therefore, similar to global variables, we introduce spv.specConstant to model three SPIR-V instructions: OpSpecConstantTrue, OpSpecConstantFalse, and OpSpecConstant. They do not return SSA value results; instead they have symbols and can only be referenced by the symbols. To use it in a function, we need to have another op spv._reference_of to turn the symbol into an SSA value. This breaks the tie and makes functions still explicit capture. Previously specialization constants were handled similarly as normal constants. That is incorrect given that specialization constant actually acts more like variable (without need to load and store). E.g., they cannot be de-duplicated like normal constants. This CL also refines various documents and comments. PiperOrigin-RevId: 264455172
* [spirv] Support (de)serialization of spv.structDenis Khalikov2019-08-202-0/+112
| | | | | | | | Support (de)serialization of spv.struct with offset decorations. Closes tensorflow/mlir#94 PiperOrigin-RevId: 264421427
* ConvertLaunchFuncToCudaCalls: use LLVM dialect globalsAlex Zinenko2019-08-201-0/+31
| | | | | | | | | | | | This conversion has been using a stack-allocated array of i8 to store the null-terminated kernel name in order to pass it to the CUDA wrappers expecting a C string because the LLVM dialect was missing support for globals. Now that the suport is introduced, use a global instead. Refactor global string construction from GenerateCubinAccessors into a common utility function living in the LLVM namespace. PiperOrigin-RevId: 264382489
* Add support for LLVM lowering of binary ops on n-D vector typesNicolas Vasilache2019-08-201-0/+5
| | | | | | This CL allows binary operations on n-D vector types to be lowered to LLVMIR by performing an (n-1)-D extractvalue, 1-D vector operation and an (n-1)-D insertvalue. PiperOrigin-RevId: 264339118
* Move Linalg and VectorOps dialects to the Dialect subdir - NFCNicolas Vasilache2019-08-1914-0/+4350
| | | | PiperOrigin-RevId: 264277760
* Fix parsing/printing of spv.globalVariable and spv._address_ofMahesh Ravishankar2019-08-191-20/+16
| | | | | | | | | | | | Change the prining/parsing of spv.globalVariable to print the type of the variable after the ':' to be consistent with MLIR convention. The spv._address_of should print the variable type after the ':'. It was mistakenly printing the address of the return value. Add a (missing) test that should have caught that. Also move spv.globalVariable and spv._address_of tests to structure-ops.mlir. PiperOrigin-RevId: 264204686
* NFC: Move LLVMIR, SDBM, and StandardOps to the Dialect/ directory.River Riddle2019-08-1918-6/+5017
| | | | PiperOrigin-RevId: 264193915
* [spirv] Add spv.ReturnValueLei Zhang2019-08-191-4/+38
| | | | | | | | | This CL adds the spv.ReturnValue op and its tests. Also adds a InFunctionScope trait to make sure that the op stays inside a function. To be consistent, ModuleOnly trait is changed to InModuleScope. PiperOrigin-RevId: 264193081
* Change from llvm::make_unique to std::make_uniqueJacques Pienaar2019-08-173-3/+3
| | | | | | | | 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
* Add spirv::GlobalVariableOp that allows module level definition of variablesMahesh Ravishankar2019-08-173-104/+473
| | | | | | | | | | | | | | | | | | | | FuncOps in MLIR use explicit capture. So global variables defined in module scope need to have a symbol name and this should be used to refer to the variable within the function. This deviates from SPIR-V spec, which assigns an SSA value to variables at all scopes that can be used to refer to the variable, which requires SPIR-V functions to allow implicit capture. To handle this add a new op, spirv::GlobalVariableOp that can be used to define module scope variables. Since instructions need an SSA value, an new spirv::AddressOfOp is added to convert a symbol reference to an SSA value for use with other instructions. This also means the spirv::EntryPointOp instruction needs to change to allow initializers to be specified using symbol reference instead of SSA value The current spirv::VariableOp which returns an SSA value (as defined by SPIR-V spec) can still be used to define function-scope variables. PiperOrigin-RevId: 263951109
OpenPOWER on IntegriCloud