summaryrefslogtreecommitdiffstats
path: root/mlir/lib/Target
Commit message (Collapse)AuthorAgeFilesLines
...
* Replace the implementation of Function and Module with FuncOp and ModuleOp.River Riddle2019-07-031-1/+1
| | | | | | This is an important step in allowing for the top-level of the IR to be extensible. FuncOp and ModuleOp contain all of the necessary functionality, while using the existing operation infrastructure. As an interim step, many of the usages of Function and Module, including the name, will remain the same. In the future, many of these will be relaxed to allow for many different types of top-level operations to co-exist. PiperOrigin-RevId: 256427100
* NFC: Refactor Module to be value typed.River Riddle2019-07-023-12/+11
| | | | | | As with Functions, Module will soon become an operation, which are value-typed. This eases the transition from Module to ModuleOp. A new class, OwningModuleRef is provided to allow for owning a reference to a Module, and will auto-delete the held module on destruction. PiperOrigin-RevId: 256196193
* NFC: Refactor Function to be value typed.River Riddle2019-07-012-17/+18
| | | | | | Move the data members out of Function and into a new impl storage class 'FunctionStorage'. This allows for Function to become value typed, which will greatly simplify the transition of Function to FuncOp(given that FuncOp is also value typed). PiperOrigin-RevId: 255983022
* Add a new AttributeElementIterator to DenseElementsAttr.River Riddle2019-06-261-3/+1
| | | | | | This allows for iterating over the internal elements via an iterator_range of Attribute, and also allows for removing the final SmallVectorImpl based 'getValues' method. PiperOrigin-RevId: 255309555
* Move the emitError/Warning/Remark utility methods out of MLIRContext and ↵River Riddle2019-06-251-12/+7
| | | | | | | | into the mlir namespace. Now that Locations are attributes, they have direct access to the MLIR context. This allows for simplifying error emission by removing unnecessary context lookups. PiperOrigin-RevId: 255112791
* NVVM target: emit nvvm.annotations for kernel functionsAlex Zinenko2019-06-252-4/+33
| | | | | | | | | | PTX backend in LLVM expects additional module-level metadata `!nvvm.annotations` that lists functions that can be used as GPU kernels. Generate this metadata based on the `gpu.kernel` attribute attached to functions. This attribute is added automatically by the kernel outlining pass in the GPU dialect lowering flow. PiperOrigin-RevId: 254957345
* Simplify usages of SplatElementsAttr now that it inherits from ↵River Riddle2019-06-191-8/+1
| | | | | | DenseElementsAttr. PiperOrigin-RevId: 253910543
* Refactor DenseElementsAttr to support auto-splatting the dense data on ↵River Riddle2019-06-191-0/+7
| | | | | | construction. This essentially means that we always auto-detect splat data and only store the minimum amount of data necessary. Support for parsing dense splats, and removing SplatElementsAttr(now that it is redundant) will come in followup cls PiperOrigin-RevId: 252720561
* Fix translation of NVVM special registers to intrinsics.Stephan Herhut2019-06-011-3/+3
| | | | | | | | | | The original implementation did not map the return value of the intrinsics call to the result value of the special register op. Uses of the result value hence hit a nullpointer. -- PiperOrigin-RevId: 250255436
* Add support for llvm.constant with StringAttr as value.Stephan Herhut2019-06-011-0/+5
| | | | | | | | | These are translated to an llvm::ConstantDataArray on translation to llvm IR proper. -- PiperOrigin-RevId: 249813111
* Refactor FunctionAttr to hold the internal function reference by name ↵River Riddle2019-06-011-3/+2
| | | | | | | | | | | | | | | | instead of pointer. The one downside to this is that the function reference held by a FunctionAttr needs to be explicitly looked up from the parent module. This provides several benefits though: * There is no longer a need to explicitly remap function attrs. - This removes a potentially expensive call from the destructor of Function. - This will enable some interprocedural transformations to now run intraprocedurally. - This wasn't scalable and forces dialect defined attributes to override a virtual function. * Replacing a function is now a trivial operation. * This is a necessary first step to representing functions as operations. -- PiperOrigin-RevId: 249510802
* Add support for streaming an OperationName into a Diagnostic.River Riddle2019-05-201-2/+1
| | | | | | -- PiperOrigin-RevId: 248987646
* Remove unnecessary C++ specifier in CPP files. NFC.Jacques Pienaar2019-05-203-3/+3
| | | | | | | | These are only required in .h files to disambiguate between C and C++ header files. -- PiperOrigin-RevId: 248219135
* Add a utility method to MLIRContext get a registered dialect with the ↵River Riddle2019-05-201-3/+2
| | | | | | | | | | | | | | derived type instead of the string name. The derived dialect type must provide a static 'getDialectNamespace' method. This means that we can now do something like: ctx->getRegisteredDialect<LLVMDialect>(); as opposed to: static_cast<LLVMDialect *>(ctx->getRegisteredDialect("llvm"); -- PiperOrigin-RevId: 247989896
* Replace Operation::isa with llvm::isa.River Riddle2019-05-201-2/+2
| | | | | | -- PiperOrigin-RevId: 247789235
* Add support for using llvm::dyn_cast/cast/isa for operation casts and ↵River Riddle2019-05-201-3/+3
| | | | | | | | replace usages of Operation::dyn_cast with llvm::dyn_cast. -- PiperOrigin-RevId: 247780086
* Automated rollback of changelist 247778391.MLIR Team2019-05-201-3/+3
| | | | PiperOrigin-RevId: 247778691
* Add support for using llvm::dyn_cast/cast/isa for operation casts and ↵River Riddle2019-05-201-3/+3
| | | | | | | | replace usages of Operation::dyn_cast with llvm::dyn_cast. -- PiperOrigin-RevId: 247778391
* Introduce a new API for emitting diagnostics with Diagnostic and ↵River Riddle2019-05-061-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | InFlightDiagnostic. The Diagnostic class contains all of the information necessary to report a diagnostic to the DiagnosticEngine. It should generally not be constructed directly, and instead used transitively via InFlightDiagnostic. A diagnostic is currently comprised of several different elements: * A severity level. * A source Location. * A list of DiagnosticArguments that help compose and comprise the output message. * A DiagnosticArgument represents any value that may be part of the diagnostic, e.g. string, integer, Type, Attribute, etc. * Arguments can be added to the diagnostic via the stream(<<) operator. * (In a future cl) A list of attached notes. * These are in the form of other diagnostics that provide supplemental information to the main diagnostic, but do not have context on their own. The InFlightDiagnostic class represents an RAII wrapper around a Diagnostic that is set to be reported with the diagnostic engine. This allows for the user to modify a diagnostic that is inflight. The internally wrapped diagnostic can be reported directly or automatically upon destruction. These classes allow for more natural composition of diagnostics by removing the restriction that the message of a diagnostic is comprised of a single Twine. They should also allow for nice incremental improvements to the diagnostics experience in the future, e.g. formatv style diagnostics. Simple Example: emitError(loc, "integer bitwidth is limited to " + Twine(IntegerType::kMaxWidth) + " bits"); emitError(loc) << "integer bitwidth is limited to " << IntegerType::kMaxWidth << " bits"; -- PiperOrigin-RevId: 246526439
* Add transformation of the NVVM dialect to an LLVM module. Only handlesStephan Herhut2019-05-065-457/+547
| | | | | | | | the generation of intrinsics out of NVVM index ops for now. -- PiperOrigin-RevId: 245933152
* Introduce std.varargs attribute to mark variadic arguments functionsMehdi Amini2019-04-071-6/+10
| | | | | | | | | | | This is only teaching the LLVM converter to propagate the attribute onto the function type. MLIR will not recognize this arguments, so it would only be useful when calling for example `printf` with the same arguments across a module. Since varargs is part of the ABI lowering, this is not NFC. -- PiperOrigin-RevId: 242382427
* ExecutionEngine: allow for running MLIR passes during JIT-compilationAlex Zinenko2019-04-071-2/+2
| | | | | | | | | | | | | | | | | The existing implementation of the ExecutionEngine unconditionally runs a list of "default" MLIR passes on the module upon creation. These passes include, among others, dialect conversions from affine to standard and from standard to LLVM IR dialects. In some cases, these conversions might have been performed before ExecutionEngine is created. More advanced use cases may be performing additional transformations that the "default" passes will conflict with. Provide an overload for ExecutionEngine::create that takes a PassManager configured with the passes to run on the module. If it is not provided, do not run any passes. The engine will not be created if the input module, after the pass manager, has any other dialect than the LLVM IR dialect. -- PiperOrigin-RevId: 242127393
* Add build files and update README.Jacques Pienaar2019-03-302-0/+10
| | | | | | | | | * Add initial version of build files; * Update README with instructions to download and build MLIR from github; -- PiperOrigin-RevId: 241102092
* Replace remaining usages of the Instruction class with Operation.River Riddle2019-03-291-27/+27
| | | | PiperOrigin-RevId: 240777521
* Replace remaining usages of "Op::operator->" with "." and remove it.River Riddle2019-03-291-6/+6
| | | | PiperOrigin-RevId: 240210336
* Remove const from Value, Instruction, Argument, and the various methods on theChris Lattner2019-03-291-10/+9
| | | | | | *Op classes. This is a net reduction by almost 400LOC. PiperOrigin-RevId: 239972443
* Remove const from mlir::Block.Chris Lattner2019-03-291-15/+14
| | | | | | This also eliminates some incorrect reinterpret_cast logic working around it, and numerous const-incorrect issues (like block argument iteration). PiperOrigin-RevId: 239712029
* Continue pushing const out of the core IR types - in this case, remove constChris Lattner2019-03-291-9/+9
| | | | | | from Function. PiperOrigin-RevId: 239638635
* Continue pushing const out of the IR types - removing the notion of a 'constChris Lattner2019-03-291-6/+5
| | | | | | Module'. NFC. PiperOrigin-RevId: 239532885
* TableGen most of the LLVM IR Dialect to LLVM IR conversionsAlex Zinenko2019-03-291-122/+23
| | | | | | | | | | | | | | | | | | | | The LLVM IR Dialect strives to be close to the original LLVM IR instructions. The conversion from the LLVM IR Dialect to LLVM IR proper is mostly mechanical and can be automated. Implement TableGen support for generating conversions from a concise pattern form in the TableGen definition of the LLVM IR Dialect operations. It is used for all operations except calls and branches. These operations need access to function and block remapping tables and would require significantly more code to generate the conversions from TableGen definitions than the current manually written conversions. This implementation is accompanied by various necessary changes to the TableGen operation definition infrastructure. In particular, operation definitions now contain named accessors to results as well as named accessors to the variadic operand (returning a vector of operands). The base operation support TableGen file now contains a FunctionAttr definition. The TableGen now allows to query the names of the operation results. PiperOrigin-RevId: 237203077
* Using llvm.noalias attribute when generating LLVMIR.Dimitrios Vytiniotis2019-03-291-1/+18
| | | | PiperOrigin-RevId: 237063104
* Use consistent names for dialect op source filesLei Zhang2019-03-291-1/+1
| | | | | | | | | | | | | | | This CL changes dialect op source files (.h, .cpp, .td) to follow the following convention: <full-dialect-name>/<dialect-namespace>Ops.{h|cpp|td} Builtin and standard dialects are specially treated, though. Both of them do not have dialect namespace; the former is still named as BuiltinOps.* and the latter is named as Ops.*. Purely mechanical. NFC. PiperOrigin-RevId: 236371358
* LLVM IR Dialect: unify call and call0 operationsAlex Zinenko2019-03-291-7/+8
| | | | | | | | | | | | | | When the LLVM IR dialect was implemented, TableGen operation definition scheme did not support operations with variadic results. Therefore, the `call` instruction was split into `call` and `call0` for the single- and zero-result calls (LLVM does not support multi-result operations). Unify `call` and `call0` using the recently added TableGen support for operations with Variadic results. Explicitly verify that the new operation has 0 or 1 results. As a side effect, this change enables clean-ups in the conversion to the LLVM IR dialect that no longer needs to rely on wrapped LLVM IR void types when constructing zero-result calls. PiperOrigin-RevId: 236119197
* Add a Function::isExternal utility to simplify checks for external functions.River Riddle2019-03-291-1/+1
| | | | PiperOrigin-RevId: 235746553
* LLVM IR dialect and translation: support conditional branches with argumentsAlex Zinenko2019-03-291-2/+6
| | | | | | | | | | | | | | | | | Since the goal of the LLVM IR dialect is to reflect LLVM IR in MLIR, the dialect and the conversion procedure must account for the differences betweeen block arguments and LLVM IR PHI nodes. In particular, LLVM IR disallows PHI nodes with different values coming from the same source. Therefore, the LLVM IR dialect now disallows `cond_br` operations that have identical successors accepting arguments, which would lead to invalid PHI nodes. The conversion process resolves the potential PHI source ambiguity by injecting dummy blocks if the same block is used more than once as a successor in an instruction. These dummy blocks branch unconditionally to the original successors, pass them the original operands (available in the dummy block because it is dominated by the original block) and are used instead of them in the original terminator operation. PiperOrigin-RevId: 235682798
* LLVM dialect conversion and target: support indirect callsAlex Zinenko2019-03-291-17/+35
| | | | | | | | | | | | | | | | | | | | Add support for converting MLIR `call_indirect` instructions to the LLVM IR dialect. In LLVM IR, the same instruction is used for direct and indirect calls. In the dialect, we have `llvm.call` and `llvm.call0` to work around the absence of the void type in MLIR. For direct calls, the callee is stored as instruction attribute. Use the same pair of instructions for indirect calls by omitting the callee attribute. In the MLIR to LLVM IR translator, check the presence of attribute to decide whether to construct a direct or an indirect call using different LLVM IR Builder functions. Add support for converting constants of function type to the LLVM IR dialect and for translating them to the LLVM IR proper. The `llvm.constant` operation works similarly to other types: its attribute has MLIR function type but the value it produces has LLVM IR function type wrapped in the dialect type. While lowering, look up the pointer to the converted function in the corresponding mapping. PiperOrigin-RevId: 234132351
* Reimplement LLVM IR translation to use the MLIR LLVM IR dialectAlex Zinenko2019-03-291-709/+317
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
* Remove remaining references to OperationInst in all directories except for ↵River Riddle2019-03-291-12/+11
| | | | | | lib/Transforms. PiperOrigin-RevId: 232322771
* Fold the functionality of OperationInst into Instruction. OperationInst ↵River Riddle2019-03-291-1/+1
| | | | | | still exists as a forward declaration and will be removed incrementally in a set of followup cleanup patches. PiperOrigin-RevId: 232198540
* Fix use of llvm::Module::getOrInsertFunction after the upstream opaque ↵River Riddle2019-03-291-5/+6
| | | | | | pointer type changes. PiperOrigin-RevId: 232002583
* Use formatv for the error instead of string stream.Jacques Pienaar2019-03-291-5/+3
| | | | PiperOrigin-RevId: 231507680
* Migrate VectorOrTensorType/MemRefType shape api to use int64_t instead of int.River Riddle2019-03-291-1/+1
| | | | PiperOrigin-RevId: 230605756
* Fix outdated commentsUday Bondhugula2019-03-291-11/+9
| | | | PiperOrigin-RevId: 229300301
* Extract openInputFile() into Support/FileUtilitiesLei Zhang2019-03-291-0/+1
| | | | | | | | | | Multiple binaries have the needs to open input files. Use this function to de-duplicate the code. Also changed openOutputFile() to return errors using std::string since it is a library call and accessing I/O in library call is not friendly. PiperOrigin-RevId: 228878221
* LLVM IR lowering: support integer division and remainder operationsAlex Zinenko2019-03-291-0/+16
| | | | | | | | | | These operations trivially map to LLVM IR counterparts for operands of scalar and (one-dimensional) vector type. Multi-dimensional vector and tensor type operands would fail type conversion before the operation conversion takes place. Add tests for scalar and vector cases. Also add a test for vector `select` instruction for consistency with other tests. PiperOrigin-RevId: 228077564
* Split the standard types from builtin types and move them into separate ↵River Riddle2019-03-291-4/+4
| | | | | | source files(StandardTypes.cpp/h). After this cl only FunctionType and IndexType are builtin types, but IndexType will likely become a standard type when the ml/cfgfunc merger is done. Mechanical NFC. PiperOrigin-RevId: 227750918
* LLVM IR Lowering: support "select"Alex Zinenko2019-03-291-0/+8
| | | | | | | This commit adds support for the "select" operation that lowers directly into its LLVM IR counterpart. A simple test is included. PiperOrigin-RevId: 227527893
* Simplify the remapFunctionAttrs logic, merging CFG/ML function handling.Chris Lattner2019-03-291-14/+11
| | | | | | | | | | | Remove an unnecessary restriction in forward substitution. Slightly simplify LLVM IR lowering, which previously would crash if given an ML function, it should now produce a clean error if given a function with an if/for instruction in it, just like it does any other unsupported op. This is step 27/n towards merging instructions and statements. PiperOrigin-RevId: 227324542
* Tidy up references to "basic blocks" that should refer to blocks now. NFC.Chris Lattner2019-03-291-2/+2
| | | | PiperOrigin-RevId: 227196077
* Standardize naming of statements -> instructions, revisting the code base to beChris Lattner2019-03-291-1/+1
| | | | | | | | | consistent and moving the using declarations over. Hopefully this is the last truly massive patch in this refactoring. This is step 21/n towards merging instructions and statements, NFC. PiperOrigin-RevId: 227178245
OpenPOWER on IntegriCloud