summaryrefslogtreecommitdiffstats
path: root/mlir/lib/IR/Module.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [mlir] Add support for attaching a visibility to symbols.River Riddle2020-01-131-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The visibility defines the structural reachability of the symbol within the IR. Symbols can define one of three visibilities: * Public The symbol \may be accessed from outside of the visible IR. We cannot assume that we can observe all of the uses of this symbol. * Private The symbol may only be referenced from within the operations in the current symbol table, via SymbolRefAttr. * Nested The symbol may be referenced by operations in symbol tables above the current symbol table, as long as each symbol table parent also defines a non-private symbol. This allows or referencing the symbol from outside of the defining symbol table, while retaining the ability for the compiler to see all uses. These properties help to reason about the properties of a symbol, and will be used in a follow up to implement a dce pass on dead symbols. A few examples of what this would look like in the IR are shown below: module @public_module { // This function can be accessed by 'live.user' func @nested_function() attributes { sym_visibility = "nested" } // This function cannot be accessed outside of 'public_module' func @private_function() attributes { sym_visibility = "private" } } // This function can only be accessed from within this module. func @private_function() attributes { sym_visibility = "private" } // This function may be referenced externally. func @public_function() "live.user"() {uses = [@public_module::@nested_function, @private_function, @public_function]} : () -> () Depends On D72043 Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D72044
* 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-1/+1
| | | | | | | | in `mlir` namespace. Aside from being cleaner, this also makes the codebase more consistent. PiperOrigin-RevId: 286206974
* Rename the current parseSymbolName to parseOptionalSymbolNameRiver Riddle2019-11-131-2/+2
| | | | | | The current implementation silently fails if the '@' identifier isn't present, making it similar to the 'optional' parse methods. This change renames the current implementation to 'Optional' and adds a new 'parseSymbolName' that emits an error. PiperOrigin-RevId: 280214610
* Add (parse|print)OptionalAttrDictWithKeyword hooks to simplify parsing ↵River Riddle2019-11-051-10/+5
| | | | | | | | attribute dictionaries with regions. Many operations with regions add an additional 'attributes' prefix when printing the attribute dictionary to differentiate it from the region body. This leads to duplicated logic for detecting when to actually print the attribute dictionary. PiperOrigin-RevId: 278747681
* NFC: Rename parseOptionalAttributeDict -> parseOptionalAttrDict to match the ↵River Riddle2019-11-051-1/+1
| | | | | | name of the print method. PiperOrigin-RevId: 278696668
* Add a utility accessor 'has_single_element' for ranges.River Riddle2019-10-301-1/+1
| | | | | | This provides an easy way to check if a range has a single element. PiperOrigin-RevId: 277544647
* Add support for parsing/printing non bare-identifier SymbolRefs.River Riddle2019-10-081-2/+4
| | | | | | The restriction that symbols can only have identifier names is arbitrary, and artificially limits the names that a symbol may have. This change adds support for parsing and printing symbols that don't fit in the 'bare-identifier' grammar by printing the reference in quotes, e.g. @"0_my_reference" can now be used as a symbol name. PiperOrigin-RevId: 273644768
* Make Module::getName return Optional<StringRef>Alex Zinenko2019-10-031-14/+12
| | | | | | | | Module names are optional so it makes more sense to take and return an optional any time the name is involved. Also update the language reference to reflect the module names. PiperOrigin-RevId: 272684698
* Give modules a nameAlex Zinenko2019-10-031-7/+31
| | | | | | | | | | Modules are now Ops and, as such, can be nested. They do not produce an SSA value so there is no possibility to refer to them in the IR. Introduce support for symbol names attached to the module Op so that it can be referred to using SymbolRefAttrs. The name is optional, for example the implicit top-level module does not have a name. PiperOrigin-RevId: 272671600
* NFC: Pass OpAsmPrinter by reference instead of by pointer.River Riddle2019-09-201-6/+6
| | | | | | 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-7/+7
| | | | | | 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-5/+5
| | | | | | MLIR follows the LLVM style of pass-by-reference. PiperOrigin-RevId: 270315612
* NFC: Fix stray character in error message: 1 -> 'River Riddle2019-09-141-1/+1
| | | | PiperOrigin-RevId: 269091468
* Verify that ModuleOps only contain dialect specific attributes.River Riddle2019-09-131-0/+8
| | | | | | ModuleOp has no expected operations, so only dialect-specific attributes are valid. PiperOrigin-RevId: 269020062
* NFC: Simplify ModuleTerminatorOp by using the HasParent trait.River Riddle2019-08-061-11/+0
| | | | PiperOrigin-RevId: 261962104
* NFC: Simplify ModuleOp by using the SingleBlockImplicitTerminator trait.River Riddle2019-08-061-18/+2
| | | | PiperOrigin-RevId: 261944712
* Update ModuleOp::create(...) to take a Location instead of a context.River Riddle2019-07-101-3/+3
| | | | | | This allows for giving a Module a more interesting location than 'Unknown'. PiperOrigin-RevId: 257310117
* Relax the restriction that Modules cannot contain operations producing results.River Riddle2019-07-091-9/+0
| | | | | | This was an arbitrary restriction caused by the way that modules were printed. Now that that has been fixed, this restriction can be removed. PiperOrigin-RevId: 257240329
* Generalize the symbol table functionality of ModuleOp into a trait ↵River Riddle2019-07-081-11/+0
| | | | | | | | '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
* NFC: Remove `Module::getFunctions` in favor of a general `getOps<T>`.River Riddle2019-07-081-1/+1
| | | | | | Modules can now contain more than just Functions, this just updates the iteration API to reflect that. The 'begin'/'end' methods have also been updated to iterate over opaque Operations. PiperOrigin-RevId: 257099084
* Replace the implementation of Function and Module with FuncOp and ModuleOp.River Riddle2019-07-031-6/+41
| | | | | | 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
* Define a ModuleOp that represents a Module as an Operation.River Riddle2019-06-221-0/+100
| | | | | | | | | | | | | | | | | | The ModuleOp contains a single region that must contain a single block. This block must be terminated by a new pseudo operation 'module_terminator'. The syntax for this operations is as follows: `module` (`attributes` attr-dict)? region Example: module { ... } module attributes { ... } { ... } PiperOrigin-RevId: 254513752
* Extract the function symbol table functionality, i.e. mapping and name ↵River Riddle2019-06-191-34/+0
| | | | | | 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
* Implement initial support for function attributes, including parser, printer,Chris Lattner2019-03-291-2/+2
| | | | | | | | | | resolver support. Still TODO are verifier support (to make sure you don't use an attribute for a function in another module) and the TODO in ModuleParser::finalizeModule that I will handle in the next patch. PiperOrigin-RevId: 209361648
* Implement a module-level symbol table for functions, enforcing uniqueness ofChris Lattner2019-03-291-0/+13
| | | | | | | names across the module and auto-renaming conflicts. Have the parser reject malformed modules that have redefinitions. PiperOrigin-RevId: 209227560
* Introduce the start of IR builder APIs, which makes it easier and less errorChris Lattner2019-03-291-3/+1
| | | | | | prone to create things. PiperOrigin-RevId: 203703229
* Implement parser/IR support for CFG functions, basic blocks and return ↵Chris Lattner2019-03-291-11/+0
| | | | | | | | | | instruction. This is pretty much minimal scaffolding for this step. Basic block arguments, instructions, other terminators, a proper IR representation for blocks/instructions, etc are all coming. PiperOrigin-RevId: 201826439
* Continue sketching out basic infrastructure, including an input and outputChris Lattner2019-03-291-0/+34
filename, and printing of trivial stuff. There is no parser yet, so the input file is ignored. PiperOrigin-RevId: 201596916
OpenPOWER on IntegriCloud