[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