summaryrefslogtreecommitdiffstats
path: root/mlir/lib/Analysis/Verifier.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: Introduce new ValuePtr/ValueRef typedefs to simplify the transition to ↵River Riddle2019-12-221-3/+3
| | | | | | | | | | Value being value-typed. This is an initial step to refactoring the representation of OpResult as proposed in: https://groups.google.com/a/tensorflow.org/g/mlir/c/XXzzKhqqF_0/m/v6bKb08WCgAJ This change will make it much simpler to incrementally transition all of the existing code to use value-typed semantics. PiperOrigin-RevId: 286844725
* Add missing include to StringMap in Verifier and DialectConversion.Jacques Pienaar2019-10-191-0/+2
| | | | PiperOrigin-RevId: 275656416
* Replace the implementation of Function and Module with FuncOp and ModuleOp.River Riddle2019-07-031-118/+2
| | | | | | 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: Move the Function/Module/Operation::verify methods out-of-line.River Riddle2019-07-021-31/+33
| | | | | | As Functions/Modules becomes operations, these methods will conflict with the 'verify' hook already on derived operation types. PiperOrigin-RevId: 256246112
* NFC: Refactor Function to be value typed.River Riddle2019-07-011-7/+7
| | | | | | 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-1/+12
| | | | | | 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
* 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
* Add a general Operation::verify that verifies an operation instance and the ↵River Riddle2019-06-111-17/+45
| | | | | | dominance of operations in any nested regions. PiperOrigin-RevId: 252529850
* NFC: Cleanup FuncVerifier and refactor it into a general OperationVerifier. ↵River Riddle2019-06-091-143/+138
| | | | | | The function specific verification has been moved into Function::verify. This is in preparation for adding a general Operation::verify method. PiperOrigin-RevId: 252065646
* Add a utility function to OperationName for extracting the dialect name.River Riddle2019-06-031-3/+2
| | | | PiperOrigin-RevId: 251333376
* Refactor FunctionAttr to hold the internal function reference by name ↵River Riddle2019-06-011-33/+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
* Simplify the emission of various diagnostics created in Analysis/ and ↵River Riddle2019-05-101-2/+2
| | | | | | | | Transforms/ by using the new diagnostic infrastructure. -- PiperOrigin-RevId: 246955332
* Add the ability to attach notes to Diagnostic/InFlightDiagnostic.River Riddle2019-05-061-3/+3
| | | | | | | | | | | | | Notes are a way to add additional context to a diagnostic, but don't really make sense as standalone diagnostics. Moving forward, notes will no longer be able to be constructed directly and must be attached to a parent Diagnostic. Notes can be attached via `attachNote`: auto diag = ...; diag.attachNote() << "This is a note"; -- PiperOrigin-RevId: 246545971
* Update the dialect attribute verification hooks to return LogicalResult ↵River Riddle2019-04-021-5/+5
| | | | | | | | instead of bool. This updates Function::emitError to return LogicalResult as well. -- PiperOrigin-RevId: 241598892
* Rewrite the verify hooks on operations to use LogicalResult instead of ↵River Riddle2019-04-021-1/+1
| | | | | | | | bool. This also changes the return of Operation::emitError/emitOpError to LogicalResult as well. -- PiperOrigin-RevId: 241588075
* Update the Function and Module verifiers to return LogicalResult instead ↵River Riddle2019-04-021-65/+64
| | | | | | | | of bool. -- PiperOrigin-RevId: 241553930
* Add a flag to Dialect that allows for dialects to enable support for ↵River Riddle2019-04-011-10/+39
| | | | | | | | | | | | | | | | | | | unregistered operations. This flag is off by default and can be toggled via the 'allowUnknownOperations(...)' method. This means that moving forward an error will be emitted for unknown operations if the dialect does not explicitly allow it. Example: func @unknown_std_op() { %0 = "std.foo_bar_op"() : () -> index return } Will result in: error: unregistered operation 'std.foo_bar_op' found in dialect ('std') that does not allow unknown operations -- PiperOrigin-RevId: 241266009
* Replace usages of Instruction with Operation in the /Analysis directory.River Riddle2019-03-291-27/+27
| | | | PiperOrigin-RevId: 240569775
* Introduce affine terminatorAlex Zinenko2019-03-291-12/+1
| | | | | | | | | | | | | | | | | | | | | | Due to legacy reasons (ML/CFG function separation), regions in affine control flow operations require contained blocks not to have terminators. This is inconsistent with the notion of the block and may complicate code motion between regions of affine control operations and other regions. Introduce `affine.terminator`, a special terminator operation that must be used to terminate blocks inside affine operations and transfers the control back to he region enclosing the affine operation. For brevity and readability reasons, allow `affine.for` and `affine.if` to omit the `affine.terminator` in their regions when using custom printing and parsing format. The custom parser injects the `affine.terminator` if it is missing so as to always have it present in constructed operations. Update transformations to account for the presence of terminator. In particular, most code motion transformation between loops should leave the terminator in place, and code motion between loops and non-affine blocks should drop the terminator. PiperOrigin-RevId: 240536998
* Replace usages of Instruction with Operation in the /IR directory.River Riddle2019-03-291-3/+3
| | | | | | This is step 2/N to renaming Instruction to Operation. PiperOrigin-RevId: 240459216
* Rename the Instruction class to Operation. This just renames the class, ↵River Riddle2019-03-291-1/+1
| | | | | | | | usages of Instruction will still refer to a typedef in the interim. This is step 1/N to renaming Instruction to Operation. PiperOrigin-RevId: 240431520
* Various small cleanups to the code, mostly removing const_cast's.Chris Lattner2019-03-291-3/+3
| | | | PiperOrigin-RevId: 240083489
* Remove const from Value, Instruction, Argument, and the various methods on theChris Lattner2019-03-291-6/+6
| | | | | | *Op classes. This is a net reduction by almost 400LOC. PiperOrigin-RevId: 239972443
* Now that ConstOpPointer is gone, we can change the various methods generated byChris Lattner2019-03-291-1/+1
| | | | | | | | | | tblgen be non-const. This requires introducing some const_cast's at the moment, but those (and lots more stuff) will disappear in subsequent patches. This significantly simplifies those patches because the various tblgen op emitters get adjusted. PiperOrigin-RevId: 239954566
* Remove const from mlir::Block.Chris Lattner2019-03-291-7/+7
| | | | | | 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-6/+6
| | | | | | from Function. PiperOrigin-RevId: 239638635
* Continue pushing const out of the IR types - removing the notion of a 'constChris Lattner2019-03-291-1/+1
| | | | | | Module'. NFC. PiperOrigin-RevId: 239532885
* Rename BlockList into RegionAlex Zinenko2019-03-291-4/+4
| | | | | | NFC. This is step 1/n to specifying regions as parts of any operation. PiperOrigin-RevId: 238472370
* Don't run verifyOperation in verifyDominance, as it is already run as part ↵River Riddle2019-03-291-14/+11
| | | | | | of verifyBlock. This caused the verifier to run in exponential time for nested regions. PiperOrigin-RevId: 237519751
* Change the TensorFlow attribute prefix from "tf$" to "tf." to match the ↵River Riddle2019-03-291-6/+2
| | | | | | specification of dialect attributes. This also fixes tblgen generation of dialect attributes that used the sugared name "tf$attr" as c++ identifiers. PiperOrigin-RevId: 236924392
* Fix dialect attribute hooks so that they accept a NamedAttribute instead of ↵River Riddle2019-03-291-3/+3
| | | | | | an Attribute. PiperOrigin-RevId: 236869321
* Introduce the notion of dialect attributes and dependent attributes. A ↵River Riddle2019-03-291-7/+48
| | | | | | | | | | | | | | | dialect attribute derives its context from a specific dialect, whereas a dependent attribute derives context from what it is attached to. Following this, we now enforce that functions and function arguments may only contain dialect specific attributes. These are generic entities and cannot provide any specific context for a dependent attribute. Dialect attributes are defined as: dialect-namespace `.` attr-name `:` attribute-value Dialects can override any of the following hooks to verify the validity of a given attribute: * verifyFunctionAttribute * verifyFunctionArgAttribute * verifyInstructionAttribute PiperOrigin-RevId: 236507970
* Add support for named function argument attributes. The attribute dictionary ↵River Riddle2019-03-291-9/+23
| | | | | | | | | | is printed after the argument type: func @arg_attrs(i32 {arg_attr: 10}) func @arg_attrs(%arg0: i32 {arg_attr: 10}) PiperOrigin-RevId: 236136830
* Allow function names to have a leading underscore. This matches what is ↵River Riddle2019-03-291-5/+5
| | | | | | already defined in the spec, but not supported in the implementation. PiperOrigin-RevId: 235823663
* Validate the names of attribute, dialect, and functions during verification. ↵River Riddle2019-03-291-33/+51
| | | | | | This essentially enforces the parsing rules upon their names. PiperOrigin-RevId: 235818842
* Add a Function::isExternal utility to simplify checks for external functions.River Riddle2019-03-291-1/+1
| | | | PiperOrigin-RevId: 235746553
* Remove the restriction that only registered terminator operations may ↵River Riddle2019-03-291-18/+36
| | | | | | terminate a block and have block operands. This allows for any operation to hold block operands. It also introduces the notion that unregistered operations may terminate a block. As such, the 'isTerminator' api on Instruction has been split into 'isKnownTerminator' and 'isKnownNonTerminator'. PiperOrigin-RevId: 233076831
* Begin the process of fully removing OperationInst. This patch cleans up ↵River Riddle2019-03-291-28/+15
| | | | | | references to OperationInst in the /include, /AffineOps, and lib/Analysis. PiperOrigin-RevId: 232199262
* 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
* Define the AffineForOp and replace ForInst with it. This patch is largely ↵River Riddle2019-03-291-14/+0
| | | | | | mechanical, i.e. changing usages of ForInst to OpPointer<AffineForOp>. An important difference is that upon construction an AffineForOp no longer automatically creates the body and induction variable. To generate the body/iv, 'createBody' can be called on an AffineForOp with no body. PiperOrigin-RevId: 232060516
* Recommit: Define a AffineOps dialect as well as an AffineIfOp operation. ↵River Riddle2019-03-291-25/+0
| | | | | | Replace all instances of IfInst with AffineIfOp and delete IfInst. PiperOrigin-RevId: 231342063
* Automated rollback of changelist 231318632.Nicolas Vasilache2019-03-291-0/+25
| | | | PiperOrigin-RevId: 231327161
* Define a AffineOps dialect as well as an AffineIfOp operation. Replace all ↵River Riddle2019-03-291-25/+0
| | | | | | instances of IfInst with AffineIfOp and delete IfInst. PiperOrigin-RevId: 231318632
* Allow operations to hold a blocklist and add support for parsing/printing a ↵River Riddle2019-03-291-7/+33
| | | | | | block list for verbose printing. PiperOrigin-RevId: 230951462
* Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead.Chris Lattner2019-03-291-15/+2
| | | | | | | | | | | | | The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
* Merge the verifier logic for all functions into a unified framework, thisChris Lattner2019-03-291-216/+148
| | | | | | | | | | requires enhancing DominanceInfo to handle the structure of an ML function, which is required anyway. Along the way, this also fixes a const correctness problem with Instruction::getBlock(). This is step 24/n towards merging instructions and statements. PiperOrigin-RevId: 227228900
* Enhance parsing of CFG and Ext functions to optionally allow named arguments inChris Lattner2019-03-291-0/+5
| | | | | | | | | | | | | | | | | the function signature, giving them common functionality to ml functions. This is a strictly additive patch that adds new capability without changing behavior in a significant way (other than a few diagnostic cleanups). A subsequent patch will change the printer to use this behavior, which will require updating a ton of testcases. :) This exposes the fact that we need to make a grammar change for block arguments, as is tracked by b/122119779 This is step 23/n towards merging instructions and statements, and one of the first steps towards eliminating the "cfg vs ml" distinction at a syntax and semantic level. PiperOrigin-RevId: 227228342
* Tidy up references to "basic blocks" that should refer to blocks now. NFC.Chris Lattner2019-03-291-3/+3
| | | | PiperOrigin-RevId: 227196077
OpenPOWER on IntegriCloud