[PATCH] D79671: [MsgPack] MsgPackDocument::readFromBlob now merges

Dineshkumar Bhaskaran via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri May 15 17:24:52 PDT 2020


dineshkb-amd added inline comments.


================
Comment at: llvm/include/llvm/BinaryFormat/MsgPackDocument.h:371
+            return (DestNode->isMap() && SrcNode.isMap()) ||
+                   (DestNode->isArray() && SrcNode.isArray());
+          });
----------------
Can we consider *DestNode = SrcNode if DestNode and SrcNode are of same type to be closer to old behavior.


================
Comment at: llvm/lib/BinaryFormat/MsgPackDocument.cpp:142
       auto &Array = Stack.back().Node.getArray();
-      Array.push_back(Node);
+      DestNode = &Array[Stack.back().Count++];
     } else {
----------------
One of the logical cases to consider for mergers involving ArrayNodes is that the "Merger" callback provider can append Node elements to DestNode. e.g. lets say the document looking like 

Root{"K1" : [ {"P" : p1} ] } is merged with Root{"K1" : ["P" : p2} ] } where {} represents a map and [] represents an array. The expected result is Root{"K1" : [ {"P" : p1}, {"P" : p2} ] } 

This is one of the cases when we deal with merging metadata in ROCm CompilerSupport. Can this be achieved with current callback if so shouldn't the Array index be modified to the number of elements added?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79671





More information about the llvm-commits mailing list