[PATCH] D125994: [NFC] Define move and copy constructors and copy assignment operators for MDOperand.

[Duncan P. N. Exon Smith via Phabricator via llvm-commits]

dexonsmith added inline comments.


================
Comment at: llvm/include/llvm/IR/Metadata.h:778
   MDOperand() = default;
-  MDOperand(MDOperand &&) = delete;
-  MDOperand(const MDOperand &) = delete;
-  MDOperand &operator=(MDOperand &&) = delete;
-  MDOperand &operator=(const MDOperand &) = delete;
+  MDOperand(const MDOperand &&Op) {
+    MD = Op.MD;
----------------
dexonsmith wrote:
> There shouldn’t be a `const` here, and `Op` should probably be reset. Is there a `retrack()` function for that operation?
Yeah, there is; `TrackingMDRef(TrackingMDRef &&X)` seems to call it.


================
Comment at: llvm/include/llvm/IR/Metadata.h:782
+  }
+  MDOperand(const MDOperand &Op) {
+    MD = Op.MD;
----------------
wolfgangp wrote:
> dexonsmith wrote:
> > I don’t think we need this and it seems better to error here. I think we should keep the copy constructor/operator deleted and make this move-only.
> In that case I'm a bit stuck because the implementation of SmallVector uses std::fill_n() and std::uninitialized_fill_n() which assign and copy the value type and want the copy constructor (at least on gcc-9). Do you have any suggestions of should we roll our own hung-off storage class after all? 
I suspect that's because the move constructor/operator had the wrong signature (an incorrect `const`). The following seems to work for me locally:
```
lang=c++
  struct MoveOnly {
    MoveOnly() = default;
    MoveOnly(MoveOnly &&) = default;
    MoveOnly &operator=(MoveOnly &&) = default;
    MoveOnly(const MoveOnly &) = delete;
    MoveOnly &operator=(const MoveOnly &) = delete;
  };
  SmallVector<MoveOnly> X;
  X.resize(10);
  X.push_back(MoveOnly());
```



================
Comment at: llvm/include/llvm/IR/Metadata.h:793
   }
   void reset(Metadata *MD, Metadata *Owner) {
     untrack();
----------------
wolfgangp wrote:
> dexonsmith wrote:
> > Looking at this, is it even safe to use the standard move operators? Seems like you don’t have a way to pass in the owner…
> IIUC (and I might be wrong there), only operands of uniqued nodes have an owner? Since we're only resizing non-uniqued nodes it seems it would probably work but how would one enforce the destination node always being non-uniqued?
Looks like `MDNode` doesn't expose non-const `MDOperand&` so it's probably safe as-is!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125994/new/

https://reviews.llvm.org/D125994