[PATCH] D105866: [lld-macho] Use intermediate arrays to store opcodes
Jez Ng via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Jul 15 11:59:42 PDT 2021
int3 added inline comments.
================
Comment at: lld/MachO/SyntheticSections.cpp:280
};
+struct BindOpcodeOpt {
+ uint8_t opcode = 0xF0;
----------------
how about `BindIR`?
================
Comment at: lld/MachO/SyntheticSections.cpp:282
+ uint8_t opcode = 0xF0;
+ uint64_t delta = 0; // Placeholder for offset or addend
+};
----------------
how about renaming it to `data` so that there's less confusion about why we're using `delta` to refer to an offset or an addend?
(alternatively we could use a union here)
================
Comment at: lld/MachO/SyntheticSections.cpp:299-300
+ BindOpcodeOpt op = {
+ static_cast<uint8_t>(BIND_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB |
+ seg->index), // opcode
+ offset // delta
----------------
cast shouldn't be necessary any more I think. I used it for writing to the stream because we would otherwise call the integer overload of the stream operator. But here there's no overload to worry about
================
Comment at: lld/MachO/SyntheticSections.cpp:303
+ };
+ opcodes.push_back(op);
lastBinding.segment = seg;
----------------
================
Comment at: lld/MachO/SyntheticSections.cpp:334
+static void flushOpcodes(BindOpcodeOpt &op, raw_svector_ostream &os) {
+ uint8_t opcode = op.opcode & 0xF0;
+ switch (opcode) {
----------------
I don't think there's anything to mask here, since we are explicitly setting `op.opcode` to one of the opcode values minus any extra data. But we could do an assert to be on the safe side :)
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D105866/new/
https://reviews.llvm.org/D105866
More information about the llvm-commits
mailing list