summaryrefslogtreecommitdiffstats
path: root/mlir/tools
Commit message (Collapse)AuthorAgeFilesLines
...
* Added a TableGen generator for structured dataRob Suderman2019-08-302-0/+260
| | | | | | Similar to enum, added a generator for structured data. This provide Dictionary that stores a fixed set of values and guarantees the values are valid. It is intended to store a fixed number of values by a given name. PiperOrigin-RevId: 266437460
* Port mlir-cuda-runner to use dialect conversion framework.Stephan Herhut2019-08-281-23/+26
| | | | | | | | | Instead of lowering the program in two steps (Standard->LLVM followed by GPU->NVVM), leading to invalid IR inbetween, the runner now uses one pattern based rewrite step to go directly from Standard+GPU to LLVM+NVVM. PiperOrigin-RevId: 265861934
* NFC: Avoid reconstructing the OpInterface methods.River Riddle2019-08-221-16/+8
| | | | PiperOrigin-RevId: 264881293
* Add support for generating operation interfaces from the ODS framework.River Riddle2019-08-212-0/+258
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Support variadic ops in declarative rewrite rulesLei Zhang2019-08-212-107/+208
| | | | | | | | | | | | | | | | | | | | | | | | This CL extends declarative rewrite rules to support matching and generating ops with variadic operands/results. For this, the generated `matchAndRewrite()` method for each pattern now are changed to * Use "range" types for the local variables used to store captured values (`operand_range` for operands, `ArrayRef<Value *>` for values, *Op for results). This allows us to have a unified way of handling both single values and value ranges. * Create local variables for each operand for op creation. If the operand is variadic, then a `SmallVector<Value*>` will be created to collect all values for that operand; otherwise a `Value*` will be created. * Use a collective result type builder. All result types are specified via a single parameter to the builder. We can use one result pattern to replace multiple results of the matched root op. When that happens, it will require specifying types for multiple results. Add a new collective-type builder. PiperOrigin-RevId: 264588559
* NFC: Don't assume that all operation traits are within the 'OpTrait::' ↵River Riddle2019-08-192-21/+23
| | | | | | | | namespace. This places an unnecessary restriction that all traits are within this namespace. PiperOrigin-RevId: 264212000
* 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-183-8/+2
| | | | | | 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
* Allow the use of the $cppClass template variable in verifier code blocks.Ben Vanik2019-08-141-3/+7
| | | | PiperOrigin-RevId: 263378198
* Add lowering of vector dialect to LLVM dialect.Nicolas Vasilache2019-08-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL is step 3/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 support for converting MLIR n-D vector types to (n-1)-D arrays of 1-D LLVM vectors and a conversion VectorToLLVM that lowers the `vector.extractelement` and `vector.outerproduct` instructions to the proper mix of `llvm.vectorshuffle`, `llvm.extractelement` and `llvm.mulf`. This has been independently verified to produce proper avx2 code. Input: ``` func @vec_1d(%arg0: vector<4xf32>, %arg1: vector<8xf32>) -> vector<8xf32> { %2 = vector.outerproduct %arg0, %arg1 : vector<4xf32>, vector<8xf32> %3 = vector.extractelement %2[0 : i32]: vector<4x8xf32> return %3 : vector<8xf32> } ``` Command: ``` mlir-opt vector-to-llvm.mlir -vector-lower-to-llvm-dialect --disable-pass-threading | mlir-opt -lower-to-cfg -lower-to-llvm | mlir-translate --mlir-to-llvmir | opt -O3 | llc -O3 -march=x86-64 -mcpu=haswell -mattr=fma,avx2 ``` Output: ``` vec_1d: # @vec_1d # %bb.0: vbroadcastss %xmm0, %ymm0 vmulps %ymm1, %ymm0, %ymm0 retq ``` PiperOrigin-RevId: 262895929
* NFC: Refactoring PatternSymbolResolver into SymbolInfoMapLei Zhang2019-08-091-247/+91
| | | | | | | | | | | | | | | In declarative rewrite rules, a symbol can be bound to op arguments or results in the source pattern, and it can be bound to op results in the result pattern. This means given a symbol in the pattern, it can stands for different things: op operand, op attribute, single op result, op result pack. We need a better way to model this complexity so that we can handle according to the specific kind a symbol corresponds to. Created SymbolInfo class for maintaining the information regarding a symbol. Also created a companion SymbolInfoMap class for a map of such symbols, providing insertion and querying depending on use cases. PiperOrigin-RevId: 262675515
* Translation to LLVM IR: use LogicalResult instead of boolAlex Zinenko2019-08-091-1/+1
| | | | | | | | The translation code predates the introduction of LogicalResult and was relying on the obsolete LLVM convention of returning false on success. Change it to use MLIR's LogicalResult abstraction instead. NFC. PiperOrigin-RevId: 262589432
* Emit matchAndRewrite() for declarative rewrite rulesLei Zhang2019-08-061-115/+107
| | | | | | | | | Previously we are emitting separate match() and rewrite() methods, which requires conveying a match state struct in a unique_ptr across these two methods. Changing to emit matchAndRewrite() simplifies the picture. PiperOrigin-RevId: 261906804
* [spirv] Provide decorations in batch for op constructionLei Zhang2019-08-061-11/+10
| | | | | | | | | | Instead of setting the attributes for decorations one by one after constructing the op, this CL changes to attach all the attributes for decorations to the attribute vector for constructing the op. This should be simpler and more efficient. PiperOrigin-RevId: 261905578
* NFC: Implement OwningRewritePatternList as a class instead of a using directive.River Riddle2019-08-052-3/+2
| | | | | | This allows for proper forward declaration, as opposed to leaking the internal implementation via a using directive. This also allows for all pattern building to go through 'insert' methods on the OwningRewritePatternList, replacing uses of 'push_back' and 'RewriteListBuilder'. PiperOrigin-RevId: 261816316
* Replace the verifyUnusedValue directive with HasNoUseOf constraintLei Zhang2019-08-011-44/+9
| | | | | | | | | verifyUnusedValue is a bit strange given that it is specified in a result pattern but used to generate match statements. Now we are able to support multi-result ops better, we can retire it and replace it with a HasNoUseOf constraint. This reduces the number of mechanisms. PiperOrigin-RevId: 261166863
* Fix support for auxiliary ops in declarative rewrite rulesLei Zhang2019-07-311-48/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We allow to generate more ops than what are needed for replacing the matched root op. Only the last N static values generated are used as replacement; the others serve as auxiliary ops/values for building the replacement. With the introduction of multi-result op support, an op, if used as a whole, may be used to replace multiple static values of the matched root op. We need to consider this when calculating the result range an generated op is to replace. For example, we can have the following pattern: ```tblgen def : Pattern<(ThreeResultOp ...), [(OneResultOp ...), (OneResultOp ...), (OneResultOp ...)]>; // Two op to replace all three results def : Pattern<(ThreeResultOp ...), [(TwoResultOp ...), (OneResultOp ...)]>; // One op to replace all three results def : Pat<(ThreeResultOp ...), (ThreeResultOp ...)>; def : Pattern<(ThreeResultOp ...), [(AuxiliaryOp ...), (ThreeResultOp ...)]>; ``` PiperOrigin-RevId: 261017235
* NFC: refactor ODS builder generationLei Zhang2019-07-311-142/+184
| | | | | | | | | | | Previously we use one single method with lots of branches to generate multiple builders. This makes the method difficult to follow and modify. This CL splits the method into multiple dedicated ones, by extracting common logic into helper methods while leaving logic specific to each builder in their own methods. PiperOrigin-RevId: 261011082
* Use operand number during serialization to get the <id>s of the operandsMahesh Ravishankar2019-07-311-1/+1
| | | | | | | | | | | During serialization, the operand number must be used to get the values assocaited with an operand. Using the argument number in Op specification was wrong since some of the elements in the arguments list might be attributes on the operation. This resulted in a segfault during serialization. Add a test that exercise that path. PiperOrigin-RevId: 260977758
* Add support for (de)serialization of SPIR-V Op DecorationsMahesh Ravishankar2019-07-301-32/+49
| | | | | | | | | | | | All non-argument attributes specified for an operation are treated as decorations on the result value and (de)serialized using OpDecorate instruction. An error is generated if an attribute is not an argument, and the name doesn't correspond to a Decoration enum. Name of the attributes that represent decoerations are to be the snake-case-ified version of the Decoration name. Add utility methods to convert to snake-case and camel-case. PiperOrigin-RevId: 260792638
* Link in MLIRGPUtoSPIRVTransforms with mlir-optMahesh Ravishankar2019-07-301-0/+1
| | | | | | | | Add a missed library that needs to be linked with mlir-opt. This results in a test failure in the MLIR due to the pass `-convert-gpu-to-spirv` not being found. PiperOrigin-RevId: 260773067
* Initial implementation to translate kernel fn in GPU Dialect to SPIR-V DialectMahesh Ravishankar2019-07-301-0/+3
| | | | | | | | | | | | | | | This CL adds an initial implementation for translation of kernel function in GPU Dialect (used with a gpu.launch_kernel) op to a spv.Module. The original function is translated into an entry function. Most of the heavy lifting is done by adding TypeConversion and other utility functions/classes that provide most of the functionality to translate from Standard Dialect to SPIR-V Dialect. These are intended to be reusable in implementation of different dialect conversion pipelines. Note : Some of the files for have been renamed to be consistent with the norm used by the other Conversion frameworks. PiperOrigin-RevId: 260759165
* RewriterGen: properly handle zero-result opsAlex Zinenko2019-07-301-3/+3
| | | | | | | | | RewriterGen was emitting invalid C++ code if the pattern required to create a zero-result operation due to the absence of a special case that would avoid generating a spurious comma. Handle this case. Also add rewriter tests for zero-argument operations. PiperOrigin-RevId: 260576998
* Enable (de)serialization support for spirv::AccessChainOpMahesh Ravishankar2019-07-301-11/+30
| | | | | | | | | | Automatic generation of spirv::AccessChainOp (de)serialization needs the (de)serialization emitters to handle argument specified as Variadic<...>. To handle this correctly, this argument can only be the last entry in the arguments list. Add a test to (de)serialize spirv::AccessChainOp PiperOrigin-RevId: 260532598
* [mlir-tblgen] Emit forward declarations for all the classes before the ↵Mehdi Amini2019-07-301-0/+8
| | | | | | | | definitions This allows classes to refer to each other in the ODS file, for instance for traits. PiperOrigin-RevId: 260532419
* Support referencing a single value generated by a matched multi-result opLei Zhang2019-07-261-18/+22
| | | | | | | | It's quite common that we want to put further constraints on the matched multi-result op's specific results. This CL enables referencing symbols bound to source op with the `__N` syntax. PiperOrigin-RevId: 260122401
* Move GPU dialect to {lib,include/mlir}/DialectAlex Zinenko2019-07-251-2/+2
| | | | | | | Per tacit agreement, individual dialects should now live in lib/Dialect/Name with headers in include/mlir/Dialect/Name and tests in test/Dialect/Name. PiperOrigin-RevId: 259896851
* [spirv] NFC: adjust `encode*` function signatures in SerializerLei Zhang2019-07-221-3/+3
| | | | | | | | | * Let them return `LogicalResult` so we can chain them together with other functions returning `LogicalResult`. * Added "Into" as the suffix to the function name and made the `binary` as the first parameter so that it reads more naturally. PiperOrigin-RevId: 259311636
* [spirv] Remove one level of indirection: processOp to processOpImplLei Zhang2019-07-221-2/+2
| | | | | | | | | | | We already have two levels of controls in SPIRVBase.td: hasOpcode and autogenSerialization. The former controls whether to add an entry to the dispatch table, while the latter controls whether to autogenerate the op's (de)serialization method specialization. This is enough for our cases. Remove the indirection from processOp to processOpImpl to simplify the picture. PiperOrigin-RevId: 259308711
* Add (de)serialization of EntryPointOp and ExecutionModeOpMahesh Ravishankar2019-07-201-1/+1
| | | | | | | | | Since the serialization of EntryPointOp contains the name of the function as well, the function serialization emits the function name using OpName instruction, which is used during deserialization to get the correct function name. PiperOrigin-RevId: 259158784
* Suppress compiler warnings regarding unused variablesLei Zhang2019-07-191-2/+2
| | | | | | | Not all ops have operands or results, so it ends up there may be no use of wordIndex or the generated op's results. PiperOrigin-RevId: 258984485
* NFC: Expose a ConversionPatternRewriter for use with ConversionPatterns.River Riddle2019-07-191-2/+3
| | | | | | This specific PatternRewriter will allow for exposing hooks in the future that are only useful for the conversion framework, e.g. type conversions. PiperOrigin-RevId: 258818122
* Automatically generate (de)serialization methods for SPIR-V opsMahesh Ravishankar2019-07-191-22/+300
| | | | | | | | | | | | | | | | For ops in SPIR-V dialect that are a direct mirror of SPIR-V operations, the serialization/deserialization methods can be automatically generated from the Op specification. To enable this an 'autogenSerialization' field is added to SPV_Ops. When set to non-zero, this will enable the automatic (de)serialization function generation Also adding tests that verify the spv.Load, spv.Store and spv.Variable ops are serialized and deserialized correctly. To fully support these tests also add serialization and deserialization of float types and spv.ptr types PiperOrigin-RevId: 258684764
* Move shared cpu runner library to Support/JitRunner.Stephan Herhut2019-07-165-357/+21
| | | | PiperOrigin-RevId: 258347825
* Extract std.for std.if and std.terminator in their own dialectNicolas Vasilache2019-07-161-0/+1
| | | | | | | These ops should not belong to the std dialect. This CL extracts them in their own dialect and updates the corresponding conversions and tests. PiperOrigin-RevId: 258123853
* Add serialization and deserialization of FuncOps. To support this theMahesh Ravishankar2019-07-121-4/+7
| | | | | | | | | | | | following SPIRV Instructions serializaiton/deserialization are added as well OpFunction OpFunctionParameter OpFunctionEnd OpReturn PiperOrigin-RevId: 257869806
* Lower affine control flow to std control flow to LLVM dialectNicolas Vasilache2019-07-123-0/+3
| | | | | | | | | | | | | This CL splits the lowering of affine to LLVM into 2 parts: 1. affine -> std 2. std -> LLVM The conversions mostly consists of splitting concerns between the affine and non-affine worlds from existing conversions. Short-circuiting of affine `if` conditions was never tested or exercised and is removed in the process, it can be reintroduced later if needed. LoopParametricTiling.cpp is updated to reflect the newly added ForOp::build. PiperOrigin-RevId: 257794436
* mcuMemHostRegister: take into account sizeof(float)Alex Zinenko2019-07-121-2/+3
| | | | | | | | cuMemHostRegister expects the size of registered memory in bytes whereas the memref descriptor in memref_t contains the number of elements. Get the actual size in bytes instead. PiperOrigin-RevId: 257589116
* Update the gen_spirv_dialect.py script to add opcodes from the SPIR-VMahesh Ravishankar2019-07-121-6/+10
| | | | | | | | JSON spec into the SPIRBase.td file. This is done incrementally to only import those opcodes that are needed, through use of the script define_opcode.sh added. PiperOrigin-RevId: 257517343
* NFC: Replace Module::getNamedFunction with lookupSymbol<FuncOp>.River Riddle2019-07-121-2/+2
| | | | | | This allows for removing the last direct reference to FuncOp from ModuleOp. PiperOrigin-RevId: 257498296
* NFC: Rename Module to ModuleOp.River Riddle2019-07-102-6/+6
| | | | | | Module is a legacy name that only exists as a typedef of ModuleOp. PiperOrigin-RevId: 257427248
* NFC: Rename Function to FuncOp.River Riddle2019-07-103-5/+5
| | | | PiperOrigin-RevId: 257293379
* Extend AffineToGPU to support Linalg loopsAlex Zinenko2019-07-091-1/+1
| | | | | | | | | | | | | | | | Extend the utility that converts affine loop nests to support other types of loops by abstracting away common behavior through templates. This also slightly simplifies the existing Affine to GPU conversion by always passing in the loop step as an additional kernel argument even though it is a known constant. If it is used, it will be propagated into the loop body by the existing canonicalization pattern and can be further constant-folded, otherwise it will be dropped by canonicalization. This prepares for the common loop abstraction that will be used for converting to GPU kernels, which is conceptually close to Linalg loops, while maintaining the existing conversion operational. PiperOrigin-RevId: 257172216
* Simplify launch_func rewrite pattern in mlir-cuda-runnerAlex Zinenko2019-07-051-6/+2
| | | | | | | Use the bulk setOperands on the cloned operation, no need to cast or iterate over the operand list. PiperOrigin-RevId: 256643496
* ODS: provide a flag to skip generation of default build methodsAlex Zinenko2019-07-051-0/+7
| | | | | | | | | | | | | | | | | | | Some operations need to override the default behavior of builders, in particular region-holding operations such as affine.for or tf.graph want to inject default terminators into the region upon construction, which default builders won't do. Provide a flag that disables the generation of default builders so that the custom builders could use the same function signatures. This is an intentionally low-level and heavy-weight feature that requires the entire builder to be implemented, and it should be used sparingly. Injecting code into the end of a default builder would depend on the naming scheme of the default builder arguments that is not visible in the ODS. Checking that the signature of a custom builder conflicts with that of a default builder to prevent emission would require teaching ODG to differentiate between types and (optional) argument names in the generated C++ code. If this flag ends up being used a lot, we should consider adding traits that inject specific code into the default builder. PiperOrigin-RevId: 256640069
* Add ODS accessors for named regions.Nicolas Vasilache2019-07-051-0/+15
| | | | PiperOrigin-RevId: 256639471
* Add an mlir-cuda-runner tool.Stephan Herhut2019-07-046-3/+363
| | | | | | | | This tool allows to execute MLIR IR snippets written in the GPU dialect on a CUDA capable GPU. For this to work, a working CUDA install is required and the build has to be configured with MLIR_CUDA_RUNNER_ENABLED set to 1. PiperOrigin-RevId: 256551415
* NFC: Refactoring to remove code bloat in SPIRV due to handling of EnumMahesh Ravishankar2019-07-033-70/+143
| | | | | | Class Attribute parsing PiperOrigin-RevId: 256471248
* [TableGen] Support creating multi-result ops in result patternsLei Zhang2019-07-031-30/+93
| | | | | | | | | | This CL introduces a new syntax for creating multi-result ops and access their results in result patterns. Specifically, if a multi-result op is unbound or bound to a name without a trailing `__N` suffix, it will act as a value pack and expand to all its values. If a multi-result op is bound to a symbol with `__N` suffix, only the N-th result will be extracted and used. PiperOrigin-RevId: 256465208
OpenPOWER on IntegriCloud