diff options
Diffstat (limited to 'mlir/g3doc/UsageOfConst.md')
| -rw-r--r-- | mlir/g3doc/UsageOfConst.md | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/mlir/g3doc/UsageOfConst.md b/mlir/g3doc/UsageOfConst.md index 052f14ddf01..5f6d3793164 100644 --- a/mlir/g3doc/UsageOfConst.md +++ b/mlir/g3doc/UsageOfConst.md @@ -10,7 +10,7 @@ understood (even though the LLVM implementation is flawed in many ways). The design team since decided to change to a different module, which eschews `const` entirely for the core IR types: you should never see a `const` method on -`Operation`, should never see the type `const Value *`, and you shouldn't feel +`Operation`, should never see the type `const ValuePtr`, and you shouldn't feel bad about this. That said, you *should* use `const` for non-IR types, like `SmallVector`'s and many other things. @@ -39,7 +39,7 @@ into the MLIR codebase, argues that the cost/benefit tradeoff of this design is a poor tradeoff, and proposes switching to a much simpler approach - eliminating the use of const of these IR types entirely. -**Note:** **This document is only discussing things like `const Value*` and +**Note:** **This document is only discussing things like `const Value` and `const Operation*`. There is no proposed change for other types, e.g. `SmallVector` references, the immutable types like `Attribute`, etc.** @@ -130,7 +130,7 @@ const. operand_iterator operand_begin(); operand_iterator operand_end(); - /// Returns an iterator on the underlying Value's (Value *). + /// Returns an iterator on the underlying Value's (ValuePtr ). operand_range getOperands(); // Support const operand iteration. @@ -141,7 +141,7 @@ const. const_operand_iterator operand_begin() const; const_operand_iterator operand_end() const; - /// Returns a const iterator on the underlying Value's (Value *). + /// Returns a const iterator on the underlying Value's (ValuePtr ). llvm::iterator_range<const_operand_iterator> getOperands() const; ArrayRef<OpOperand> getOpOperands() const { |
