[Lldb-commits] [PATCH] D76449: [lldb/Dwarf] Change DW_OP_piece to use an llvm::BitVector

[Vedant Kumar via Phabricator via lldb-commits]

vsk added a reviewer: labath.
vsk added a comment.

Excited to see this take shape :)



================
Comment at: lldb/source/Expression/DWARFExpression.cpp:935
 
   /// Insertion point for evaluating multi-piece expression.
+  llvm::BitVector bit_pieces;
----------------
Stale comment here, would be nice to describe the purpose of the two bitvectors.


================
Comment at: lldb/source/Expression/DWARFExpression.cpp:1261
     case DW_OP_const1u:
-      stack.push_back(Scalar((uint8_t)opcodes.GetU8(&offset)));
+      stack.push_back(Scalar((unsigned int)opcodes.GetU8(&offset)));
       break;
----------------
I don't really understand a bunch of these changes. Is the idea to prevent implicit conversion to a type with the wrong size/signedness? I think that should really be tackled separately. We can make `Scalar`'s constructors safe like this: https://godbolt.org/z/APUMA6

(basically stick `template<typename T, std::enable_if_t<std::is_same<T, $whateverType>::value, int> = 0>` in front of each overload)


================
Comment at: lldb/source/Expression/DWARFExpression.cpp:2505
+      Value pieces;
+      pieces.AppendBytes(bit_pieces.getData().data(), bit_pieces.size() / 8);
       result = pieces;
----------------
Can we assert that this doesn't drop any bits (bit_pieces.size() % 8 == 0)?


================
Comment at: lldb/source/Utility/Scalar.cpp:200
   case e_uint512:
-    return (m_integer.getBitWidth() / 8);
+    return ceil(m_integer.getBitWidth() / 8.0);
   case e_float:
----------------
aprantl wrote:
> ?
This is worth a comment, I'm not sure what this is for.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76449