This is an archive of the discontinued LLVM Phabricator instance.

[Clang] Use std::move in GlobalModuleIndex::readIndex. NFC
ClosedPublic

Authored by junaire on Apr 8 2022, 7:45 PM.

Details

Summary

BitstreamCursors are heavy-weight objects that should not be passed by value.

Diff Detail

Event Timeline

junaire created this revision.Apr 8 2022, 7:45 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 8 2022, 7:45 PM
Herald added a subscriber: arphaman. · View Herald Transcript
junaire requested review of this revision.Apr 8 2022, 7:45 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 8 2022, 7:45 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
RKSimon added inline comments.Apr 9 2022, 2:58 AM
clang/lib/Serialization/GlobalModuleIndex.cpp
130

You're not passing this as a const, so the calling function's Cursor will be updated - this doesn't sound generally safe to me - what about a move?

junaire added inline comments.Apr 9 2022, 4:41 AM
clang/lib/Serialization/GlobalModuleIndex.cpp
130

You're not passing this as a const, so the calling function's Cursor will be updated - this doesn't sound generally safe to me - what about a move?

IIUC, GlobalModuleIndex::GlobalModuleIndex is a private function that has only been called by GlobalModuleIndex::readIndex, and the Cursor object has only one consumer (GlobalModuleIndex::readIndex), so I guess there should not be any unsafe concern.

Perhaps GlobalModuleIndex should create the cursor itself - it's being handed the buffer anyway?

junaire updated this revision to Diff 425134.Apr 26 2022, 12:21 AM

use std::move().

I'm not sure this will be better but hope it will make others happy :)

junaire retitled this revision from [Clang] Pass llvm::BitstreamCursor by reference. NFC to [Clang] Use std::move in GlobalModuleIndex::readIndex. NFC.Apr 26 2022, 12:22 AM
RKSimon accepted this revision.Apr 26 2022, 1:13 AM

LGTM

This revision is now accepted and ready to land.Apr 26 2022, 1:13 AM
This revision was landed with ongoing or failed builds.Apr 26 2022, 1:45 AM
This revision was automatically updated to reflect the committed changes.

Perhaps GlobalModuleIndex should create the cursor itself - it's being handed the buffer anyway?

Ping on this ^ - would this be a better direction that addresses the concerns?

Perhaps GlobalModuleIndex should create the cursor itself - it's being handed the buffer anyway?

Ping on this ^ - would this be a better direction that addresses the concerns?

Sorry about missing this! :(
However, I'm not sure that I understand your idea. Do you mean we can simply pass the buffer to the GlobalModuleIndex then we can construct the cursor in the constructor itself? IMHO, we can't. that's because we need to use the cursor to sniff for the signature of the buffer, and we will return an error if it is failed. Please let me know if I understand you wrong :)

  /// The main bitstream cursor for the main block.
  llvm::BitstreamCursor Cursor(*Buffer);

  // Sniff for the signature.
  for (unsigned char C : {'B', 'C', 'G', 'I'}) {
    if (Expected<llvm::SimpleBitstreamCursor::word_t> Res = Cursor.Read(8)) {
      if (Res.get() != C)
        return std::make_pair(
            nullptr, llvm::createStringError(std::errc::illegal_byte_sequence,
                                             "expected signature BCGI"));
    } else
      return std::make_pair(nullptr, Res.takeError());
  }

  return std::make_pair(new GlobalModuleIndex(std::move(Buffer), std::move(Cursor)),
                        llvm::Error::success());
}

Perhaps GlobalModuleIndex should create the cursor itself - it's being handed the buffer anyway?

Ping on this ^ - would this be a better direction that addresses the concerns?

Sorry about missing this! :(
However, I'm not sure that I understand your idea. Do you mean we can simply pass the buffer to the GlobalModuleIndex then we can construct the cursor in the constructor itself?

That's what I meant, yeah - since the buffer is actually already being passed.

IMHO, we can't. that's because we need to use the cursor to sniff for the signature of the buffer, and we will return an error if it is failed. Please let me know if I understand you wrong :)

Ah, right ,I missed that usage before the call. Makes sense then - thanks for helping me understand!