[llvm] [NFC][LLVM] Refactor MachineInstr operand accessors (PR #137261)

Sergei Barannikov via llvm-commits llvm-commits at lists.llvm.org
Fri Apr 25 08:27:27 PDT 2025


================
@@ -676,68 +672,61 @@ class MachineInstr
   const_mop_iterator operands_begin() const { return Operands; }
   const_mop_iterator operands_end() const { return Operands + NumOperands; }
 
-  iterator_range<mop_iterator> operands() {
-    return make_range(operands_begin(), operands_end());
+  MutableArrayRef<MachineOperand> operands() {
----------------
s-barannikov wrote:

> I am not sure. It only makes it impossible if someone assumes that the return type of operands() is an ArrayRef, with code like:
> 
> `ArrayRef<MCOperand> ops = MI.operands();`

`MI.operands.size()` and `operands()[i]` used in this PR already expose sequential nature of the data structure.
They are used internally, but nothing prevents clients from doing the same making them "non-well behaving".

> Even today, we cannot change the storage to a segregated arrays without changing the return type of operands().

It doesn't need to be changed? We can change `mop_iterator` from pointer to full-blown iterator and clients won't notice the change.


https://github.com/llvm/llvm-project/pull/137261


More information about the llvm-commits mailing list