summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
| * NFC: Update Ch.1 of the Toy tutorial.River Riddle2019-08-233-19/+23
| | | | | | | | | | | | Change the use of 'array' to 'tensor' to reflect the new flow that the tutorial will follow. Also tidy up some of the documentation, code comments, and fix a few out-dated links. PiperOrigin-RevId: 265174676
| * Lower linalg.copy to LLVM dialect in the presence of transposes.Nicolas Vasilache2019-08-233-15/+95
| | | | | | | | | | | | | | | | | | | | 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-233-4/+141
| | | | | | | | | | | | | | | | | | | | | | | | 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-234-10/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * NFC: Add a note to 'applyPatternsGreedily' that it also performs folding/dce.River Riddle2019-08-232-3/+4
| | | | | | | | | | | | Fixes tensorflow/mlir#72 PiperOrigin-RevId: 265097597
| * Add lowering of linalg.copy to an external C++ library and a test.Nicolas Vasilache2019-08-234-8/+59
| | | | | | | | | | | | 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
| * Update Linalg slice and subview documentation - NFCNicolas Vasilache2019-08-231-15/+17
| | | | | | | | PiperOrigin-RevId: 265092922
| * [spirv] NFC: move SPIR-V control flow ops to a separate fileLei Zhang2019-08-235-120/+155
| | | | | | | | | | | | This CL is also purely moving code around for better file organization. PiperOrigin-RevId: 265092566
| * Introduce the ability for "isolated from above" ops to introduce shadowingChris Lattner2019-08-235-11/+85
| | | | | | | | | | | | names for the basic block arguments in their body. PiperOrigin-RevId: 265084627
| * NFC: Update in-code documentation. Make the two grammar definitions of ↵MLIR Team2019-08-231-3/+5
| | | | | | | | | | | | static-dimension-list consistent. PiperOrigin-RevId: 265084348
| * [spirv] NFC: move arithmetic and logical ops to separate filesLei Zhang2019-08-238-1144/+1217
| | | | | | | | | | | | This is purely moving code around for better file organization. PiperOrigin-RevId: 265082517
| * Fix BufferAllocOp builder.Nicolas Vasilache2019-08-231-1/+4
| | | | | | | | | | | | One of the BufferAllocOp builders was improperly specified which triggered infinite recursion. This CL fixes it. PiperOrigin-RevId: 265080371
| * NFC: Move the operation, region, and block sections to after the dialect ↵River Riddle2019-08-231-297/+275
| | | | | | | | | | | | | | | | section. Operations/Regions/Blocks represent the core IR building blocks and should be introduced before types and attributes. PiperOrigin-RevId: 265079103
| * Add I32ElementsAttr to OpBaseMLIR Team2019-08-223-0/+41
| | | | | | | | PiperOrigin-RevId: 264969142
| * Add iterator support to ElementsAttr and SparseElementsAttr.River Riddle2019-08-224-35/+309
| | | | | | | | | | | | This will allow iterating the values of a non-opaque ElementsAttr, with all of the types currently supported by DenseElementsAttr. This should help reduce the amount of specialization on DenseElementsAttr. PiperOrigin-RevId: 264968151
| * NFC: Cleanup the Attribute section in the LangRef.River Riddle2019-08-221-50/+116
| | | | | | | | | | | | | | | | * Add a section on dialect attribute values and attribute aliases * Move FloatAttr into its alphabetically correct place * Add a "Standard Attribute Values" section PiperOrigin-RevId: 264959306
| * NFC: Cleanup the type system section of the LangRef.River Riddle2019-08-221-166/+163
| | | | | | | | | | | | | | | | * Alphabetize the type definitions * Make 'Dialect specific types' a type-system subsection * Merge Builtin types and Standard types PiperOrigin-RevId: 264947721
| * [spirv] Add support for extension (de)serializationLei Zhang2019-08-226-19/+128
| | | | | | | | | | | | | | Only a few important KHR extensions are registered to the SPIR-V dialect for now. PiperOrigin-RevId: 264939428
| * NFC: Rework and cleanup the High-Level structure and Dialect sections.River Riddle2019-08-221-110/+105
| | | | | | | | | | | | Both sections are out-of-date and need to be updated. The dialect section is particularly bad in that it never actually mentions what a 'Dialect' is. PiperOrigin-RevId: 264937905
| * NFC: Remove mentions of the TensorFlow dialect from the langref.River Riddle2019-08-221-44/+4
| | | | | | | | PiperOrigin-RevId: 264904489
| * Avoid overflow when lowering linalg.sliceNicolas Vasilache2019-08-223-34/+66
| | | | | | | | | | | | | | | | 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
| * NFC: Avoid reconstructing the OpInterface methods.River Riddle2019-08-221-16/+8
| | | | | | | | PiperOrigin-RevId: 264881293
| * [spirv] Add support for capability (de)serializationLei Zhang2019-08-226-20/+312
| | | | | | | | | | | | | | This CL pulls in capabilities defined in the spec and adds support for (de)serialize capabilities of a spv.module. PiperOrigin-RevId: 264877413
| * Add Positive{I32,I64}Attr and HasAnyRankOfPredLogan Chien2019-08-224-0/+98
| | | | | | | | | | | | | | | | This commit adds `PositiveI32Attr` and `PositiveI64Attr` to match positive integers but not zero nor negative integers. This commit also adds `HasAnyRankOfPred` to match tensors with the specified ranks. PiperOrigin-RevId: 264867046
| * Split out parsing location into separate functions per instanceJacques Pienaar2019-08-221-107/+127
| | | | | | | | | | | | Split out method into specialized instances + add an early exit. Should be NFC, but simplifies reading the logic slightly IMHO. PiperOrigin-RevId: 264855529
| * Let LLVMOpLowering specify a PatternBenefit - NFCNicolas Vasilache2019-08-222-4/+4
| | | | | | | | | | | | Currently the benefit is always set to 1 which limits the ability to do A->B->C lowering PiperOrigin-RevId: 264854146
| * NFC: Fix path of LinalgLibraryOpInterfaces inc files.River Riddle2019-08-222-2/+2
| | | | | | | | PiperOrigin-RevId: 264827908
| * Add support for generating operation interfaces from the ODS framework.River Riddle2019-08-219-154/+437
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * Avoid assigning to an unchecked Error.River Riddle2019-08-211-10/+14
| | | | | | | | | | | | Fixes tensorflow/mlir#97 PiperOrigin-RevId: 264743395
| * Point to spv.AccessChain when reporting spv.AccessChain errorsLei Zhang2019-08-212-9/+8
| | | | | | | | PiperOrigin-RevId: 264742130
| * Remove dead getLLVMLibraryCallImplDefinition in Linalg's ↵Nicolas Vasilache2019-08-211-27/+4
| | | | | | | | | | | | LowerToLLVMDialect.cpp - NFC PiperOrigin-RevId: 264740014
| * Reduce reliance on custom grown Jit implementation - NFCNicolas Vasilache2019-08-213-215/+150
| | | | | | | | | | | | | | | | | | | | This CL makes use of the standard LLVM LLJIT and removes the need for a custom JIT implementation within MLIR. To achieve this, one needs to clone (i.e. serde) the produced llvm::Module into a new LLVMContext. This is currently necessary because the llvm::LLVMContext is owned by the LLVMDialect, somewhat deep in the call hierarchy. In the future we should remove the reliance of serding the llvm::Module by allowing the injection of an LLVMContext from the top-level. Unfortunately this will require deeper API changes and impact multiple places. It is therefore left for future work. PiperOrigin-RevId: 264737459
| * Remove the wrapping function in SPIR-V (de)serializationLei Zhang2019-08-2117-488/+412
| | | | | | | | | | | | | | | | | | 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
| * NFC: Update in-code documentation for type.MLIR Team2019-08-211-3/+3
| | | | | | | | PiperOrigin-RevId: 264734014
| * Fix minor typos in TestingGuide and OpDefinitions.Chintan Kaur2019-08-212-6/+6
| | | | | | | | PiperOrigin-RevId: 264733092
| * NFC: Update in-code documentation for function-type.MLIR Team2019-08-211-1/+1
| | | | | | | | PiperOrigin-RevId: 264723462
| * Add a hook to the OpAsmDialectInterface to allow providing a special name ↵River Riddle2019-08-213-24/+57
| | | | | | | | | | | | | | | | for the operation result. This generalizes the current special handling for constant operations(they get named 'cst'/'true'/'false'/etc.) PiperOrigin-RevId: 264723379
| * [TableGen] Add a `StaticShapeMemRefOf` trait.MLIR Team2019-08-213-0/+18
| | | | | | | | | | | | The trait specifies that the `MemRefOf` has to have a static shape. PiperOrigin-RevId: 264692758
| * Automated rollback of commit b9dc2e481818315f2f0d87455349f497f6118a4cRiver Riddle2019-08-214-300/+35
| | | | | | | | PiperOrigin-RevId: 264672975
| * NFC: Make the ModuleState field in the ModulePrinter optional.River Riddle2019-08-211-43/+35
| | | | | | | | | | | | The ModuleState is only used for printing aliases, which is only done when printing the top-level module. PiperOrigin-RevId: 264664138
| * Add iterator support to ElementsAttr and SparseElementsAttr.River Riddle2019-08-214-35/+300
| | | | | | | | | | | | This will allow iterating the values of a non-opaque ElementsAttr, with all of the types currently supported by DenseElementsAttr. This should help reduce the amount of specialization on DenseElementsAttr. PiperOrigin-RevId: 264637293
| * Move the parser extensions for aliases currently on Dialect to a new ↵River Riddle2019-08-215-28/+85
| | | | | | | | | | | | | | | | OpAsmDialectInterface. This will allow for adding more hooks for controlling parser behavior without bloating Dialect in the common case. This cl also adds iteration support to the DialectInterfaceCollection. PiperOrigin-RevId: 264627846
| * [spirv] Support i1 as bool typeLei Zhang2019-08-213-13/+26
| | | | | | | | PiperOrigin-RevId: 264612014
| * Support variadic ops in declarative rewrite rulesLei Zhang2019-08-216-127/+482
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * Materialize spv.constants at use sitesLei Zhang2019-08-213-148/+233
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Keep the dialect list in the context sorted by namespace.River Riddle2019-08-201-6/+14
| | | | | | | | | | | | Most dialects are initialized statically, which does not have a guaranteed initialization order. By keeping the dialect list sorted, we can guarantee a deterministic iteration order of dialects. PiperOrigin-RevId: 264522875
| * NFC: Use a DenseSet instead of a DenseMap for DialectInterfaceCollection.River Riddle2019-08-202-7/+26
| | | | | | | | | | | | The interfaces are looked up by dialect, which can always be retrieved from an interface instance. PiperOrigin-RevId: 264516023
| * NFC: Move the LangRef documentation on StandardOps to a new document.River Riddle2019-08-203-947/+956
| | | | | | | | | | | | The LangRef should contain documentation about the core system, and standard ops is a dialect just like any other. This will also simplify the transition when StandardOps is eventually split apart. PiperOrigin-RevId: 264514988
| * NFC: Move AffineOps dialect to the Dialect sub-directory.River Riddle2019-08-2046-51/+51
| | | | | | | | PiperOrigin-RevId: 264482571
| * Add spv.specConstant and spv._reference_ofLei Zhang2019-08-207-260/+658
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud