summaryrefslogtreecommitdiffstats
path: root/mlir/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Change from llvm::make_unique to std::make_uniqueJacques Pienaar2019-08-1745-68/+68
| | | | | | | | 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
* NFC: Add header blocks to improve readability.River Riddle2019-08-171-2/+10
| | | | PiperOrigin-RevId: 263951251
* Add spirv::GlobalVariableOp that allows module level definition of variablesMahesh Ravishankar2019-08-174-115/+485
| | | | | | | | | | | | | | | | | | | | 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
* NFC: Modernize and cleanup standard ops.River Riddle2019-08-161-64/+46
| | | | PiperOrigin-RevId: 263891926
* NFC: Refactor the PassInstrumentation framework to operate on Operation ↵River Riddle2019-08-163-45/+38
| | | | | | | | instead of llvm::Any. Now that functions and modules are operations, Operation makes more sense as the opaque object to refer to both. PiperOrigin-RevId: 263883913
* NFC: Move the Type::is* predicates to StandardTypes.cppRiver Riddle2019-08-161-0/+26
| | | | | | These methods are currently defined 'inline' in StandardTypes.h, but this may create linker errors if StandardTypes.h isn't included at the use site. PiperOrigin-RevId: 263850328
* [spirv] Extend spv.array with LayoutinfoDenis Khalikov2019-08-164-20/+107
| | | | | | | | Extend spv.array with Layoutinfo to support (de)serialization. Closes tensorflow/mlir#80 PiperOrigin-RevId: 263795304
* Refactor DialectConversion to convert the signatures of blocks when they are ↵River Riddle2019-08-161-33/+41
| | | | | | | | moved. Often we want to ensure that block arguments are converted before operations that use them. This refactors the current implementation to be cleaner/less frequent by triggering conversion when a set of blocks are moved/inlined; or when legalization is successful. PiperOrigin-RevId: 263795005
* Extend vector.outerproduct with an optional 3rd argumentNicolas Vasilache2019-08-162-71/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL adds an optional third argument to the vector.outerproduct instruction. When such a third argument is specified, it is added to the result of the outerproduct and is lowered to FMA intrinsic when the lowering supports it. In the future, we can add an attribute on the `vector.outerproduct` instruction to modify the operations for which to emit code (e.g. "+/*", "max/+", "min/+", "log/exp" ...). This CL additionally performs minor cleanups in the vector lowering and adds tests to improve coverage. This has been independently verified to result in proper fma instructions for haswell as follows. Input: ``` func @outerproduct_add(%arg0: vector<17xf32>, %arg1: vector<8xf32>, %arg2: vector<17x8xf32>) -> vector<17x8xf32> { %2 = vector.outerproduct %arg0, %arg1, %arg2 : vector<17xf32>, vector<8xf32> return %2 : vector<17x8xf32> } } ``` 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: ``` outerproduct_add: # @outerproduct_add # %bb.0: ... vmovaps 112(%rbp), %ymm8 vbroadcastss %xmm0, %ymm0 ... vbroadcastss 64(%rbp), %ymm15 vfmadd213ps 144(%rbp), %ymm8, %ymm0 # ymm0 = (ymm8 * ymm0) + mem ... vfmadd213ps 400(%rbp), %ymm8, %ymm9 # ymm9 = (ymm8 * ymm9) + mem ... ``` PiperOrigin-RevId: 263743359
* Simplify the classes that support SPIR-V conversion.Mahesh Ravishankar2019-08-152-31/+35
| | | | | | | | | | | | | | | | | | | | Modify the Type converters to have a SPIRVBasicTypeConverter which only handles conversion from standard types to SPIRV types. Rename SPIRVEntryFnConverter to SPIRVTypeConverter. This contains the SPIRVBasicTypeConverter within it. Remove SPIRVFnLowering class and have separate utility methods to lower a function as entry function or a non-entry function. The current setup could end with diamond inheritence that is not very friendly to use. For example, you could define the following Op conversion methods that lower from a dialect "Foo" which resuls in diamond inheritance. template<typename OpTy> class FooDialect : public SPIRVOpLowering<OpTy> {...}; class FooFnLowering : public FooDialect, SPIRVFnLowering {...}; PiperOrigin-RevId: 263597101
* Add BuiltIn EnumAttr to SPIR-V dialectMahesh Ravishankar2019-08-153-7/+50
| | | | | | | | | | Generate the EnumAttr to represent BuiltIns in SPIR-V dialect. The builtIn can be specified as a StringAttr with value being the name of the builtin. Extend Decoration (de)serialization to handle BuiltIns. Also fix an error in the SPIR-V dialect generator script. PiperOrigin-RevId: 263596624
* ExecutionEngine: fix after upstream LLVM ORC updateAlex Zinenko2019-08-151-5/+6
| | | | | | | | LLVM r368707 updated the APIs in llvm::orc::DynamicLibrarySearchGenerator to use unique_ptr for holding the instance of the generator. Update our uses of DynamicLibrarySearchGenerator in the ExecutionEngine to reflect that. PiperOrigin-RevId: 263539855
* Add support for Dialect interfaces.River Riddle2019-08-141-1/+42
| | | | | | | | | | Dialect interfaces are virtual apis registered to a specific dialect instance. Dialect interfaces are generally useful for transformation passes, or analyses, that want to opaquely operate on operations within a given dialect. These interfaces generally involve wide coverage over the entire dialect. A dialect interface can be defined by inheriting from the CRTP base class DialectInterfaceBase::Base. This class provides the necessary utilities for registering an interface with the dialect so that it can be looked up later. Dialects overriding an interface may register an instance via 'Dialect::addInterfaces'. This API works very similarly to the respective addOperations/addTypes/etc. This will allow for a transformation/utility to later query the interface from an opaque dialect instance via 'getInterface<T>'. A utility class 'DialectInterfaceCollection' is also provided that will collect all of the dialects that implement a specific interface within a given module. This allows for simplifying the API of interface lookups. PiperOrigin-RevId: 263489015
* Refactor ElementsAttr::getValue and DenseElementsAttr::getSplatValue.River Riddle2019-08-145-86/+89
| | | | | | All 'getValue' variants now require that the index is valid, queryable via 'isValidIndex'. 'getSplatValue' now requires that the attribute is a proper splat. This allows for querying these methods on DenseElementAttr with all possible value types; e.g. float, int, APInt, etc. This also allows for removing unnecessary conversions to Attribute that really want the underlying value. PiperOrigin-RevId: 263437337
* Move remaining linalg ops to ODS - NFCNicolas Vasilache2019-08-142-277/+190
| | | | | | | | This CL moves the linalg.load/range/store ops to ODS. Minor cleanups are performed. Additional invalid IR tests are added for coverage. PiperOrigin-RevId: 263432110
* Refactor linalg.view lowering to LLVM - NFCNicolas Vasilache2019-08-141-36/+26
| | | | | | This CL fuses the emission of size and stride information and makes it clearer which indexings are stepped over when querying the positions. This refactor was motivated by an index calculation bug in the stride computation. PiperOrigin-RevId: 263341610
* Move linalg.slice to ODSNicolas Vasilache2019-08-144-128/+82
| | | | PiperOrigin-RevId: 263334168
* Add unreachable to avoid GCC -Wreturn-type warningjpienaar2019-08-131-0/+3
| | | | | | | | GCC warns of control reaching end of non-void function (-Wreturn-type). Closes tensorflow/mlir#75 PiperOrigin-RevId: 263214601
* Fix indexing issue in lowering of linalg.sliceNicolas Vasilache2019-08-131-3/+6
| | | | | | | | | | This CL fixes the stepping through operands when emitting the view sizes of linalg.slice to LLVMIR. This is now consistent with the strides emission. A relevant test is added. Fix suggested by Alex Zinenko, thanks! PiperOrigin-RevId: 263150922
* GenerateCubinAccessors: use LLVM dialect constantsAlex Zinenko2019-08-131-70/+48
| | | | | | | | | | | | The GenerateCubinAccessors was generating functions that fill dynamically-allocated memory with the binary constant of a CUBIN attached as a stirng attribute to the GPU kernel. This approach was taken to circumvent the missing support for global constants in the LLVM dialect (and MLIR in general). Global constants were recently added to the LLVM dialect. Change the GenerateCubinAccessors pass to emit a global constant array of characters and a function that returns a pointer to the first character in the array. PiperOrigin-RevId: 263092052
* Express ownership transfer in PassManager API through std::unique_ptr (NFC)Mehdi Amini2019-08-1236-93/+108
| | | | | | | | | | | | | | 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
* Use unreachable post switch rather than default case.Jacques Pienaar2019-08-121-4/+2
| | | | | | | | Prefer to enumerate all cases in the switch instead of using default to allow compiler to flag missing cases. This also avoids -Wcovered-switch-default warning. PiperOrigin-RevId: 262935972
* Avoid passing in line/col for files not registered with SourceMgr.Jacques Pienaar2019-08-121-6/+4
| | | | | | | | | This can result in index expression overflow in "Loc.getPointer() - ColumnNo" in SourgeMgr. loc could also be prefixed to the message additionally in this case. PiperOrigin-RevId: 262935408
* LLVM dialect: introduce llvm.addressof to access globalsAlex Zinenko2019-08-122-9/+66
| | | | | | | | | | | This instruction is a local counterpart of llvm.global that takes a symbol reference to a global and produces an SSA value containing the pointer to it. Used in combination, these two operations allow one to use globals with other operations expecting SSA values. At a cost of IR indirection, we make sure the functions don't implicitly capture the surrounding SSA values and remain suitable for parallel processing. PiperOrigin-RevId: 262908622
* Add lowering of vector dialect to LLVM dialect.Nicolas Vasilache2019-08-124-10/+235
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Update pattern rewrite API to pass OwningRewritePatternList by const ↵River Riddle2019-08-113-32/+31
| | | | | | | | reference. The pattern list is not modified by any of these APIs and should thus be passed with const. PiperOrigin-RevId: 262844002
* Refactor DenseElementAttr::getValues methods to return full ranges for splats.River Riddle2019-08-113-22/+39
| | | | | | The current implementation only returns one element for the splat case, which often comes as a surprise; leading to subtle/confusing bugs. The new behavior will include an iterate over the full range of elements, as defined by the shaped type, by providing the splat value for each iterator index. PiperOrigin-RevId: 262756780
* NFC: Standardize the terminology used for parent ops/regions/etc.River Riddle2019-08-0913-40/+40
| | | | | | There are currently several different terms used to refer to a parent IR unit in 'get' methods: getParent/getEnclosing/getContaining. This cl standardizes all of these methods to use 'getParent*'. PiperOrigin-RevId: 262680287
* NFC: Refactoring PatternSymbolResolver into SymbolInfoMapLei Zhang2019-08-091-35/+184
| | | | | | | | | | | | | | | 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
* NFC: Update usages of OwningRewritePatternList to pass by & instead of &&.River Riddle2019-08-0915-32/+27
| | | | | | This will allow for reusing the same pattern list, which may be costly to continually reconstruct, on multiple invocations. PiperOrigin-RevId: 262664599
* Translation to LLVM IR: use LogicalResult instead of boolAlex Zinenko2019-08-092-32/+28
| | | | | | | | 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
* LLVM dialect and translation: support global stringsAlex Zinenko2019-08-092-4/+50
| | | | | | | | | | | Unlike regular constant values, strings must be placed in some memory and referred to through a pointer to that memory. Until now, they were not supported in function-local constant declarations with `llvm.constant`. Introduce support for global strings using `llvm.global`, which would translate them into global arrays in LLVM IR and thus make sure they have some memory allocated for storage. PiperOrigin-RevId: 262569316
* Translation to LLVM: support llvm.globalAlex Zinenko2019-08-091-0/+10
| | | | | | | Add support for translating recently introduced llvm.global operations to global variables in the LLVM IR proper. PiperOrigin-RevId: 262564700
* External library name mangling support for linalg.Nicolas Vasilache2019-08-092-17/+50
| | | | | | | | | | This CL introduces the ability to generate the external library name for Linalg operations. The problem is that neither mlir or C support overloading and we want a simplified form of name mangling that is still reasonable to read. This CL creates the name of the external call that Linalg expects from the operation name and the type of its arguments. The interface library names are updated and use new cases are added for FillOp. PiperOrigin-RevId: 262556833
* Allow linalg.view to change the underlying elemental type.Nicolas Vasilache2019-08-094-92/+82
| | | | | | | | | This CL adds the ability for linalg.view to act as a bitcast operation. This will be used when promoting views into faster memory and casting to vector types. In the process, linalg.view is moved to ODS. PiperOrigin-RevId: 262556246
* Add a higher-order vector.outerproduct operation in MLIRNicolas Vasilache2019-08-091-0/+44
| | | | | | | | 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.outerproduct operation to the MLIR vector dialect as well as the appropriate roundtrip test. Lowering to LLVM will occur in the following CL. PiperOrigin-RevId: 262552027
* Add a higher-order vector.extractelement operation in MLIRNicolas Vasilache2019-08-098-13/+104
| | | | | | | | 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
* Add support for vector ops in the LLVM dialectNicolas Vasilache2019-08-091-0/+151
| | | | | | | | | | | | This CL is step 1/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 3 instructions `llvm.extractelement`, `llvm.insertelement` and `llvm.shufflevector` as documented in the LLVM LangRef "Vector Instructions" section. The "Experimental Vector Reduction Intrinsics" are left out for now and can be added in the future on a per-need basis. Appropriate roundtrip and LLVM Target tests are added. PiperOrigin-RevId: 262542095
* LLVM Dialect: introduce llvm.globalAlex Zinenko2019-08-092-0/+76
| | | | | | | | | | | Introduce an operation that defines global constants and variables in the LLVM dialect, to reflect the corresponding LLVM IR capability. This operation is expected to live in the top-level module and behaves similarly to llvm.constant. It currently does not model many of the attributes supported by the LLVM IR for global values (memory space, alignment, thread-local, linkage) and will be extended as the relevant use cases appear. PiperOrigin-RevId: 262539445
* Add support for floating-point comparison 'fcmp' to the LLVM dialect.Nagy Mostafa2019-08-084-29/+143
| | | | | | | | This adds support for fcmp to the LLVM dialect and adds any necessary lowerings, as well as support for EDSCs. Closes tensorflow/mlir#69 PiperOrigin-RevId: 262475255
* Enable TTI for host TargetMachine in JitRunnerDiego Caballero2019-08-081-1/+13
| | | | | | | | | | | | | | This commit improves JitRunner so that it creates a target machine for the current CPU host which is used to properly initialize LLVM's TargetTransformInfo for such a target. This will enable optimizations such as vectorization in LLVM when using JitRunner. Please, note that, as part of this work, JITTargetMachineBuilder::detectHost() has been extended to include the host CPU name and sub-target features as part of the host CPU detection (https://reviews.llvm.org/D65760). Closes tensorflow/mlir#71 PiperOrigin-RevId: 262452525
* Build SymbolTable upfront in ModuleOp verification.Mahesh Ravishankar2019-08-081-1/+2
| | | | | | | | Building the symbol table upfront from module op allows for O(1) lookup of the function while verifying duplicate EntryPointOp within the module. PiperOrigin-RevId: 262435697
* Add SymbolTable trait to spirv::ModuleOp.Mahesh Ravishankar2019-08-081-9/+4
| | | | | | | | Adding the SymbolTable trait allows looking up the name of the functions using the symbol table while verifying EntryPointOps instead of manually tracking the function names. PiperOrigin-RevId: 262431220
* Lexer: NFC: sort helper methods alphabeticallyAlex Zinenko2019-08-082-97/+97
| | | | | | | | Lexer methods were added progressively as implementation advanced. The rest of MLIR now tends to sort methods alphabetically for better discoverability in absence of tooling. Sort the lexer methods as well. PiperOrigin-RevId: 262406992
* FunctionSupport: wrap around bool to have a more semantic callback typeAlex Zinenko2019-08-084-10/+13
| | | | | | | | | | | | This changes the type of the function type-building callback from (ArrayRef<Type>, ArrayRef<Type>, bool, string &) to (ArrayRef<Type>, ArrayRef<Type>, VariadicFlag, String &) to make the intended use clear from the callback signature alone. Also rearrange type definitions in Parser.cpp to make them more sorted alphabetically. PiperOrigin-RevId: 262405851
* Introduce support for variadic function signatures for the LLVM dialectAlex Zinenko2019-08-087-19/+73
| | | | | | | | | | | | | LLVM function type has first-class support for variadic functions. In the current lowering pipeline, it is emulated using an attribute on functions of standard function type. In LLVMFuncOp that has LLVM function type, this can be modeled directly. Introduce parsing support for variadic arguments to the function and use it to support variadic function declarations in LLVMFuncOp. Function definitions are currently not supported as that would require modeling va_start/va_end LLVM intrinsics in the dialect and we don't yet have a consistent story for LLVM intrinsics. PiperOrigin-RevId: 262372651
* Parser: treat implicit top-level module as an SSA name scopeAlex Zinenko2019-08-081-1/+5
| | | | | | | | | | Now that modules are also operations, nothing prevents one from defining SSA values in the module. Doing so in an implicit top-level module, i.e. outside of a `module` operation, was leading to a crash because the implicit module was not associated with an SSA name scope. Create a name scope before parsing the top-level module to fix this. PiperOrigin-RevId: 262366891
* Add canonicalization pattern for linalg.dimNicolas Vasilache2019-08-081-0/+84
| | | | | | | | This CL introduces canonicalization patterns for linalg.dim. This allows the dimenions of chains of view, slice and subview operations to simplify. Down the line, when mixed with cse, this also allows better composition of linalg tiling and fusion by tracking operations that give the same result (not in this CL). PiperOrigin-RevId: 262365865
* NFC: Update FuncOp::addEntryBlock to return the newly inserted block.River Riddle2019-08-073-6/+4
| | | | | | The entry block is often used recently after insertion. This removes the need to perform an additional lookup in such cases. PiperOrigin-RevId: 262265671
* Initialize local variables for opcode to fix MSAN failuresLei Zhang2019-08-071-3/+3
| | | | PiperOrigin-RevId: 262225919
OpenPOWER on IntegriCloud