summaryrefslogtreecommitdiffstats
path: root/mlir/lib/IR/Value.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [mlir] NFC: Remove Value::operator* and Value::operator-> now that Value is ↵River Riddle2020-01-111-3/+3
| | | | | | | | | | properly value-typed. Summary: These were temporary methods used to simplify the transition. Reviewed By: antiagainst Differential Revision: https://reviews.llvm.org/D72548
* [mlir] Rewrite the internal representation of OpResult to be optimized for ↵River Riddle2020-01-021-0/+97
| | | | | | | | | | | | | | memory. Summary: This changes the implementation of OpResult to have some of the results be represented inline in Value, via a pointer int pair of Operation*+result number, and the rest being trailing objects on the main operation. The full details of the new representation is detailed in the proposal here: https://groups.google.com/a/tensorflow.org/g/mlir/c/XXzzKhqqF_0/m/v6bKb08WCgAJ The only difference between here and the above proposal is that we only steal 2-bits for the Value kind instead of 3. This means that we can only fit 2-results inline instead of 6. This allows for other users to steal the final bit for PointerUnion/etc. If necessary, we can always steal this bit back in the future to save more space if 3-6 results are common enough. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D72020
* Fix some corner cases missed by D71955River Riddle2020-01-021-0/+5
| | | | | | * replaceAllUsesWith may be supplied with a null value. * some compilers fail to implicitly convert single result operations to OpaqueValue, so add an explicit OpOperand::set(Value) method.
* [mlir] Refactor operation results to use a single use list for all results ↵River Riddle2019-12-301-26/+69
| | | | | | | | | | of the operation. Summary: A new class is added, IRMultiObjectWithUseList, that allows for representing an IR use list that holds multiple sub values(used in this case for OpResults). This class provides all of the same functionality as the base IRObjectWithUseList, but for specific sub-values. This saves a word per operation result and is a necessary step in optimizing the layout of operation results. For now the use list is placed on the operation itself, so zero-result operations grow by a word. When the work for optimizing layout is finished, this can be moved back to being a trailing object based on memory/runtime benchmarking. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D71955
* [mlir] Merge the successor operand count into BlockOperand.River Riddle2019-12-271-0/+33
| | | | | | | | Summary: The successor operand counts are directly tied to block operands anyways, and this simplifies the trailing objects of Operation(i.e. one less computation to perform). Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D71949
* Resubmit: ReImplement the Value classes as value-typed objects wrapping an ↵River Riddle2019-12-231-2/+2
| | | | | | | | internal pointer storage. This will enable future commits to reimplement the internal implementation of OpResult without needing to change all of the existing users. This is part of a chain of commits optimizing the size of operation results. PiperOrigin-RevId: 286930047
* Automated rollback of commit f603a50109107b447b835dac11f0eb541288393eMLIR Team2019-12-231-2/+2
| | | | PiperOrigin-RevId: 286924059
* ReImplement the Value classes as value-typed objects wrapping an internal ↵River Riddle2019-12-231-2/+2
| | | | | | | | pointer storage. This will enable future commits to reimplement the internal implementation of OpResult without needing to change all of the existing users. This is part of a chain of commits optimizing the size of operation results. PiperOrigin-RevId: 286919966
* 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-2/+2
| | | | | | | | | | 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
* NFC: Replace usages of Value::getKind with explicit isa/casts.River Riddle2019-10-141-7/+3
| | | | | | It is more idiomatic to use the llvm::cast infrastructure for checking the type of a value. PiperOrigin-RevId: 274684945
* NFC: Standardize the terminology used for parent ops/regions/etc.River Riddle2019-08-091-2/+2
| | | | | | 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: Rename Function to FuncOp.River Riddle2019-07-101-1/+0
| | | | PiperOrigin-RevId: 257293379
* NFC: Remove the various "::getFunction" methods.River Riddle2019-07-081-30/+1
| | | | | | These methods assume that a function is a valid builtin top-level operation, and removing these methods allows for decoupling FuncOp and IR/. Utility "getParentOfType" methods have been added to Operation/OpState to allow for querying the first parent operation of a given type. PiperOrigin-RevId: 257018913
* NFC: Refactor Function to be value typed.River Riddle2019-07-011-4/+4
| | | | | | 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 llvm_unreachable in unreachable path to silence GCC warning (NFC)Mehdi Amini2019-05-101-0/+2
| | | | | | | | | The switch is supposed to be fully covered, but GCC warns that: "control reaches end of non-void function" -- PiperOrigin-RevId: 247672430
* Introduce functionality for defining region ancestor relationAlex Zinenko2019-05-061-0/+11
| | | | | | | | | | | | Add member functions for Regions to query if another Region is a ancestor. The implementation is naive and traverses all parent regions performing one-to-one comparisons. As a side effect, this introduces `getContainingRegion` function for Operations and Values to return the Region in which they are defined, and for Regions to return the "parent" region if any. -- PiperOrigin-RevId: 245057980
* Add a getLoc() method on mlir::Value that returns the loc of the ↵Mehdi Amini2019-04-011-0/+7
| | | | | | | | defining Operations if any, otherwise an unknown location -- PiperOrigin-RevId: 241354085
* Replace usages of Instruction with Operation in the /IR directory.River Riddle2019-03-291-6/+6
| | | | | | 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
* Remove const from Value, Instruction, Argument, and the various methods on theChris Lattner2019-03-291-3/+3
| | | | | | *Op classes. This is a net reduction by almost 400LOC. PiperOrigin-RevId: 239972443
* Continue pushing const out of the core IR types - in this case, remove constChris Lattner2019-03-291-2/+2
| | | | | | from Function. PiperOrigin-RevId: 239638635
* Begin the process of fully removing OperationInst. This patch cleans up ↵River Riddle2019-03-291-1/+1
| | | | | | 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
* Fold IROperandOwner into Instruction.River Riddle2019-03-291-9/+1
| | | | PiperOrigin-RevId: 232159334
* Define the AffineForOp and replace ForInst with it. This patch is largely ↵River Riddle2019-03-291-2/+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-2/+0
| | | | | | Replace all instances of IfInst with AffineIfOp and delete IfInst. PiperOrigin-RevId: 231342063
* Automated rollback of changelist 231318632.Nicolas Vasilache2019-03-291-0/+2
| | | | PiperOrigin-RevId: 231327161
* Define a AffineOps dialect as well as an AffineIfOp operation. Replace all ↵River Riddle2019-03-291-2/+0
| | | | | | instances of IfInst with AffineIfOp and delete IfInst. PiperOrigin-RevId: 231318632
* Change the ForInst induction variable to be a block argument of the body ↵River Riddle2019-03-291-2/+6
| | | | | | instead of the ForInst itself. This is a necessary step in converting ForInst into an operation. PiperOrigin-RevId: 231064139
* Drop all uses of the ForInst induction variable before deleting ForInstAlex Zinenko2019-03-291-0/+7
| | | | | | | | | | | | | | | | The `for` instruction defines the loop induction variable it uses. In the well-formed IR, the induction variable can only be used by the body of the `for` loop. Existing implementation was explicitly cleaning the body of the for loop to remove all uses of the induction variable before removing its definition. However, in ill-formed IR that may appear in some stages of parsing, there may be (invalid) users of the loop induction variable outside the loop body. In case of unsuccessful parsing, destructor of the ForInst-defined Value would assert because there are remaining though invalid users of this Value. Explicitly drop all uses of the loop induction Value when destroying a ForInst. It is no longer necessary to explicitly clean the body of the loop, destructor of the block will take care of this. PiperOrigin-RevId: 228168880
* Standardize naming of statements -> instructions, revisting the code base to beChris Lattner2019-03-291-7/+7
| | | | | | | | | 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
* Eliminate the using decls for MLFunction and CFGFunction standardizing onChris Lattner2019-03-291-1/+1
| | | | | | | | Function. This is step 18/n towards merging instructions and statements, NFC. PiperOrigin-RevId: 227139399
* Rename BBArgument -> BlockArgument, Op::getOperation -> Op::getInst(),Chris Lattner2019-03-291-1/+1
| | | | | | | | StmtResult -> InstResult, StmtOperand -> InstOperand, and remove the old names. This is step 17/n towards merging instructions and statements, NFC. PiperOrigin-RevId: 227121537
* Merge Operation into OperationInst and standardize nomenclature aroundChris Lattner2019-03-291-20/+4
| | | | | | | | OperationInst. This is a big mechanical patch. This is step 16/n towards merging instructions and statements, NFC. PiperOrigin-RevId: 227093712
* Rework inherentance hierarchy: Operation now derives from Statement, andChris Lattner2019-03-291-6/+0
| | | | | | | | | | | | | OperationInst derives from it. This allows eliminating some forwarding functions, other complex code handling multiple paths, and the 'isStatement' bit tracked by Operation. This is the last patch I think I can make before the big mechanical change merging Operation into OperationInst, coming next. This is step 15/n towards merging instructions and statements, NFC. PiperOrigin-RevId: 227077411
* Merge CFGFuncBuilder/MLFuncBuilder/FuncBuilder together into a single newChris Lattner2019-03-291-0/+100
FuncBuilder class. Also rename SSAValue.cpp to Value.cpp This is step 12/n towards merging instructions and statements, NFC. PiperOrigin-RevId: 227067644
OpenPOWER on IntegriCloud