summaryrefslogtreecommitdiffstats
path: root/mlir/lib/IR/Function.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [mlir] NFC: Remove Value::operator* and Value::operator-> now that Value is ↵River Riddle2020-01-111-2/+2
| | | | | | | | | | properly value-typed. Summary: These were temporary methods used to simplify the transition. Reviewed By: antiagainst Differential Revision: https://reviews.llvm.org/D72548
* Adjust License.txt file to use the LLVM licenseMehdi Amini2019-12-231-13/+4
| | | | PiperOrigin-RevId: 286906740
* NFC: Remove unnecessary 'llvm::' prefix from uses of llvm symbols declared ↵River Riddle2019-12-181-3/+3
| | | | | | | | in `mlir` namespace. Aside from being cleaner, this also makes the codebase more consistent. PiperOrigin-RevId: 286206974
* Split out FunctionLike printing/parsing into FunctionImplementation.{h,cpp}Alex Zinenko2019-11-281-0/+1
| | | | | | | | | | | Helper utilies for parsing and printing FunctionLike Ops are only relevant to the implementation of the Op, not its definition. They depend on OpImplementation.h and increase the inclusion footprint of FunctionSupport.h, and do so only to provide some utilities in the "impl" namespace. Move them to a separate files, similarly to OpDefinition/OpImplementation distinction, and make only Op implementations use them while keeping headers cleaner. NFC. PiperOrigin-RevId: 282964556
* Add FuncOp::eraseArgumentSean Silva2019-11-131-0/+35
| | | | | | | | | | | | This is a quite complex operation that users are likely to attempt to write themselves and get wrong (citation: users=me). Ideally, we could pull this into FunctionLike, but for now, the FunctionType rewriting makes it FuncOp specific. We would need some hook for rewriting the function type (which for LLVM's func op, would need to rewrite the underlying LLVM type). PiperOrigin-RevId: 280234164
* NFC: Remove trivial builder get methods.River Riddle2019-10-171-1/+1
| | | | | | These don't add any value, and some are even more restrictive than the respective static 'get' method. PiperOrigin-RevId: 275391240
* NFC: Pass OpAsmPrinter by reference instead of by pointer.River Riddle2019-09-201-1/+1
| | | | | | MLIR follows the LLVM style of pass-by-reference. PiperOrigin-RevId: 270401378
* NFC: Pass OperationState by reference instead of by pointer.River Riddle2019-09-201-10/+10
| | | | | | MLIR follows the LLVM convention of passing by reference instead of by pointer. PiperOrigin-RevId: 270396945
* NFC: Pass OpAsmParser by reference instead of by pointer.River Riddle2019-09-201-1/+1
| | | | | | MLIR follows the LLVM style of pass-by-reference. PiperOrigin-RevId: 270315612
* [spirv] Add support for spv.loop (de)serializationLei Zhang2019-09-111-0/+8
| | | | | | | | This CL adds support for serializing and deserializing spv.loop ops. This adds support for spv.Branch and spv.BranchConditional op (de)serialization, too, because they are needed for spv.loop. PiperOrigin-RevId: 268536962
* FunctionSupport: wrap around bool to have a more semantic callback typeAlex Zinenko2019-08-081-1/+2
| | | | | | | | | | | | 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-081-5/+9
| | | | | | | | | | | | | 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
* NFC: Update FuncOp::addEntryBlock to return the newly inserted block.River Riddle2019-08-071-1/+2
| | | | | | The entry block is often used recently after insertion. This removes the need to perform an additional lookup in such cases. PiperOrigin-RevId: 262265671
* Introduce custom syntax for llvm.funcAlex Zinenko2019-08-051-3/+2
| | | | | | | Similar to all LLVM dialect operations, llvm.func needs to have the custom syntax. Use the generic FunctionLike printer and parser to implement it. PiperOrigin-RevId: 261641755
* Genericize function-like printer and parser. NFCAlex Zinenko2019-07-251-160/+7
| | | | | | | | | | | | | Function-like operations are likely to have similar custom syntax, in particular they all need to print function signature with argument attributes. Transform function printer and parser so that they can be applied to any operation with the FunctionLike trait. Move them to the trait itself. To avoid large member functions in the class template, define a concrete base class for the trait and implement common functionality in it. This allows printer and parser to be implemented in a source file without templating. PiperOrigin-RevId: 260020893
* Introduce LLVMFuncOpAlex Zinenko2019-07-231-99/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally, MLIR only supported functions of the built-in FunctionType. On the conversion path to LLVM IR, we were creating MLIR functions that contained LLVM dialect operations and used LLVM IR types for everything expect top-level functions (e.g., a second-order function would have a FunctionType that consume or produces a wrapped LLVM function pointer type). With MLIR functions becoming operations, it is now possible to introduce non-built-in function operations. This will let us use conversion patterns for function conversion, simplify the MLIR-to-LLVM translation by removing the knowledge of the MLIR built-in function types, and provide stronger correctness verifications (e.g. LLVM functions only accept LLVM types). Furthermore, we can currently construct a situation where the same function is used with two different types: () -> () when its specified and called directly, and !llvm<"void ()"> when it's passed somewhere on called indirectly. Having a special function-op that is always of !llvm<"void ()"> type makes the function model and the llvm dialect type system more consistent. Introduce LLVMFuncOp to represent a function in the LLVM dialect. Unlike standard FuncOp, this function has an LLVMType wrapping an LLVM IR function type. Generalize the common behavior of function-defining operations (functions live in a symbol table of a module, contain a single region, are iterable as a list of blocks, and support argument attributes). This only defines the operation. Custom syntax, conversion and translation rules will be added in follow-ups. The operation name mentions LLVM explicitly to avoid confusion with standard FuncOp, especially in multiple files that use both `mlir` and `mlir::LLVM` namespaces. PiperOrigin-RevId: 259550940
* Update the dialect attribute verifiers related to functions.River Riddle2019-07-121-3/+4
| | | | | | Remove the Function specific attribute verifier in favor of the general operation verifier. This also generalizes the function argument verifier to allow use for an argument attached to any region of any operation. PiperOrigin-RevId: 257689962
* Rename FunctionAttr to SymbolRefAttr.River Riddle2019-07-121-2/+2
| | | | | | This allows for the attribute to hold symbolic references to other operations than FuncOp. This also allows for removing the dependence on FuncOp from the base Builder. PiperOrigin-RevId: 257650017
* FuncOp::eraseBody: drop all references before erasing blocksAlex Zinenko2019-07-121-0/+8
| | | | | | | | | | Operations in a block can use a value defined in a dominating block. When a block, and therefore all its operations, is deleted, the operations are not allowed to have any remaining uses. Drop all uses of values in all blocks before deleting them in FuncOp::eraseBody to avoid deleting an operation before deleting the users of its results. PiperOrigin-RevId: 257628002
* Drop the trailing newline from the FuncOp syntax.River Riddle2019-07-121-4/+1
| | | | | | The ModulePrinter prints the newline now for children of the top-level module. This also fixes the location printing for functions as the location used to be printed on a different line. PiperOrigin-RevId: 257447633
* NFC: Remove Function::getModule.River Riddle2019-07-121-6/+0
| | | | | | There is already a more general 'getParentOfType' method, and 'getModule' is likely to be misused as functions get placed within different regions than ModuleOp. PiperOrigin-RevId: 257442243
* NFC: Rename Function to FuncOp.River Riddle2019-07-101-10/+10
| | | | PiperOrigin-RevId: 257293379
* Generalize the symbol table functionality of ModuleOp into a trait ↵River Riddle2019-07-081-3/+17
| | | | | | | | 'OpTrait::SymbolTable'. Operations must only contain a single region. Once attached, all operations that contain a 'mlir::SymbolTable::getSymbolAttrName()' StringAttr attribute within the child region will be verified to ensure that the names are uniqued. Operations using this trait also gain access to the 'SymbolTable' class, which can be used to manage the symbol table of the operation. This class also provides constant-time lookup of symbols by name, and will automatically rename symbols on insertion. PiperOrigin-RevId: 257123573
* Replace the implementation of Function and Module with FuncOp and ModuleOp.River Riddle2019-07-031-165/+116
| | | | | | 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-021-7/+9
| | | | | | 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: Update the Operation 'walk' methods to use llvm::function_ref instead ↵River Riddle2019-07-021-1/+1
| | | | | | of std::function. PiperOrigin-RevId: 256099638
* NFC: Refactor Function to be value typed.River Riddle2019-07-011-26/+33
| | | | | | 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
* Extract the automatic function renaming and symbol table out of Module.River Riddle2019-07-011-8/+1
| | | | | | This functionality is now moved to a new class, ModuleManager. This class allows for inserting functions into a module, and will auto-rename them on insert to ensure a unique name. This now means that users adding new functions to a module must ensure that the function name is unique, as the Module will no longer do it automatically. This also means that Module::getNamedFunction now operates in O(N) instead of the O(c) time it did before. This simplifies the move of Modules to Operations as the ModuleOp will not be able to have this functionality. PiperOrigin-RevId: 255846088
* Cleanup the 'clone' methods and remove the need to explicitly pass in the ↵River Riddle2019-06-271-1/+1
| | | | | | | | context. This also adds a new 'Region::cloneInto' method that accepts an insertion position. PiperOrigin-RevId: 255504640
* Move the emitError/Warning/Remark utility methods out of MLIRContext and ↵River Riddle2019-06-251-3/+3
| | | | | | | | 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
* Extract the function symbol table functionality, i.e. mapping and name ↵River Riddle2019-06-191-28/+3
| | | | | | uniquing, out of Module and into a new class SymbolTable. As modules become operations it is necessary to extract out this functionality that cannot be represented with a generic operation. PiperOrigin-RevId: 254041734
* Add a utility to OpAsmPrinter for printing an optional trailing arrow type ↵River Riddle2019-06-191-21/+1
| | | | | | list. This is useful for any operation that wants to print a set of types in the same format as a FunctionType/Operation signature. PiperOrigin-RevId: 252647152
* Add a verify method to FuncOp and check that the type signature matches the ↵River Riddle2019-06-091-0/+23
| | | | | | signature of the entry block. PiperOrigin-RevId: 251759848
* Add a few utility overloads for OpAsmParser methods:River Riddle2019-06-091-2/+1
| | | | | | | * Add a getCurrentLocation that returns the location directly. * Add parseOperandList/parseTrailingOperandList overloads without the required operand count. PiperOrigin-RevId: 251585488
* NFC: Rename FuncBuilder to OpBuilder and refactor to take a top level region ↵River Riddle2019-06-091-3/+1
| | | | | | instead of a function. PiperOrigin-RevId: 251563898
* Add support to FuncOp for managing argument attributes. The syntax for ↵River Riddle2019-06-091-20/+79
| | | | | | | | | | | | argument attributes is the same as Function: func @foo(i1 {dialect.attr: 10 : i64}) func @foo(%arg0: i1 {dialect.attr: 10 : i64}) { return } PiperOrigin-RevId: 251473338
* Start defining a new operation 'FuncOp' that replicates all of the ↵River Riddle2019-06-031-0/+200
| | | | | | functionality of 'Function', but with an operation. The pretty syntax for the operation is exactly the same as that of Function. This operation is currently builtin, but should hopefully be moved to a different dialect when it has been completely decoupled from IR/. This is the first patch in a large series that refactors Functions to be represented as operations. PiperOrigin-RevId: 251281612
* Refactor FunctionAttr to hold the internal function reference by name ↵River Riddle2019-06-011-5/+0
| | | | | | | | | | | | | | | | 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
* Allow a function to take the name of another existing function.River Riddle2019-05-201-0/+8
| | | | | | -- PiperOrigin-RevId: 248968285
* Refactor the includes of Function.h now that the dependency on Operation ↵River Riddle2019-05-201-3/+5
| | | | | | | | has been removed. The dependency was on the op casting methods, which have now moved out of Operation, used by the walker. -- PiperOrigin-RevId: 247944666
* Simplify several usages of attributes now that they always have a type ↵River Riddle2019-05-101-4/+2
| | | | | | | | | | and, transitively, access to the context. This also fixes a bug where FunctionAttrs were not being remapped for function and function argument attributes. -- PiperOrigin-RevId: 246876924
* Make the Twine parameter of the current diagnostic emit functions ↵River Riddle2019-05-061-10/+10
| | | | | | | | optional. This allows for the ability to exclusively use the new diagnostic interface without breaking all of the existing usages. Several diagnostics emitted in lib/IR have been updated to make use of this functionality. -- PiperOrigin-RevId: 246546044
* Add an MLIRContext::emitWarning utility method.River Riddle2019-05-061-3/+1
| | | | | | -- PiperOrigin-RevId: 246546015
* Introduce a new API for emitting diagnostics with Diagnostic and ↵River Riddle2019-05-061-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 support for basic remark diagnostics. This is the minimal ↵River Riddle2019-05-061-6/+5
| | | | | | | | functionality needed to separate notes from remarks. It also provides a starting point to start building out better remark infrastructure. -- PiperOrigin-RevId: 246175216
* Start sketching out a new diagnostics infrastructure. Create a new class ↵River Riddle2019-05-061-4/+5
| | | | | | | | 'DiagnosticEngine' and move the diagnostic handler support and final diagnostic emission from the MLIRContext to it. -- PiperOrigin-RevId: 246163897
* Remove the non-postorder walk functions from Function/Block/Instruction ↵River Riddle2019-04-051-6/+0
| | | | | | | | and rename walkPostOrder to walk. -- PiperOrigin-RevId: 241965239
* Update the dialect attribute verification hooks to return LogicalResult ↵River Riddle2019-04-021-4/+4
| | | | | | | | instead of bool. This updates Function::emitError to return LogicalResult as well. -- PiperOrigin-RevId: 241598892
* Simplify API uses of `getContext()` (NFC)Mehdi Amini2019-03-291-1/+1
| | | | | | The Pass base class is providing a convenience getContext() accessor. PiperOrigin-RevId: 240634961
* Replace usages of Instruction with Operation in the /IR directory.River Riddle2019-03-291-5/+4
| | | | | | This is step 2/N to renaming Instruction to Operation. PiperOrigin-RevId: 240459216
OpenPOWER on IntegriCloud