Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[nfc][InstrFDO]Encapsulate header writes in a class member function #90142

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

minglotus-6
Copy link
Contributor

The smaller class member are more focused and easier to maintain. This also paves the way for partial header forward compatibility in #88212

InfoObj->CSSummaryBuilder = &CSISB;

// Populate the hash table generator.
SmallVector<std::pair<StringRef, const ProfilingData *>, 0> OrderedData;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know why the size hint = 0?

I guess this is old code just being moved in this patch but we can drop the hint since now SmallVector can infer the size hint automatically.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done.

if (!WritePrevVersion)
OS.write(0);

return OS.tell() - StartOffset;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this returned value isn't being used then maybe update the definition and call site? Also you can just return a HeaderFieldOffsets struct instead of passing it in by reference.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the review @snehasish !

Before making changes for the other comments, just a quick question on the return value: the subsequent patch for partial forward compatibility (#88212) needs header byte size (for reader to locate the end of the header fields), and InstrProfWriter::writeHeader is the function that has the header byte size information.

To make the diff smaller for the subsequent patch, I wonder if returning std::pair<uint64_t /* ByteSize*/, HeaderFieldOffsets> sounds good.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah makes sense. I would suggest just leave a FIXME comment that the returned value will be used in a future patch at the call site.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done by using a FIXME at the callsite.

Also chose (void) rather than std::ignore after I searched the differences and came across transmission/transmission#3667 (comment)

@@ -197,13 +197,26 @@ class InstrProfWriter {
const OverlapFuncFilters &FuncFilter);

private:
struct HeaderFieldOffsets {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a comment describing what this struct holds and how the contents are used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done.

Copy link
Contributor Author

@minglotus-6 minglotus-6 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ptal, thanks!

InfoObj->CSSummaryBuilder = &CSISB;

// Populate the hash table generator.
SmallVector<std::pair<StringRef, const ProfilingData *>, 0> OrderedData;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done.

@@ -197,13 +197,26 @@ class InstrProfWriter {
const OverlapFuncFilters &FuncFilter);

private:
struct HeaderFieldOffsets {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done.

if (!WritePrevVersion)
OS.write(0);

return OS.tell() - StartOffset;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done by using a FIXME at the callsite.

Also chose (void) rather than std::ignore after I searched the differences and came across transmission/transmission#3667 (comment)

@kazutakahirata
Copy link
Contributor

Instead of grouping the offsets of header fields into a struct, could we add a couple of member functions to llvm::IndexedInstrProf::Header instead?

struct Header {
  // ... existing stuff ...

  uint64_t HeaderPos;

  // Write out the header, including placeholders for various offsets.
  void write(ProfOStream &OS, bool WritePrevVersion) {
    // Only write out the first four fields.
    for (int I = 0; I < 4; I++)
      OS.write(reinterpret_cast<uint64_t *>(&Header)[I]);

    UpdatePos = OS.tell();
    OS.write(0);  // HashTableStart
    OS.write(0);  // MemProfSectionStart
    OS.write(0);  // BinaryIdSectionStart
    ...
    // Do whatever is appropriate with WritePrevVersion.
  }

  // Update the header.
  void patch(ProfOStream &OS, bool WritePrevVersion) {
    uint64_t Updates[] = {HashTableStart, MemProfSectionStart, BinaryIdSectionStart, ...};
    OS.patch({{UpdatePos, Updates, std::size(Updates)}});
    // Do whatever is appropriate with WritePrevVersion.
  }
};

This way, we can remove variables like HashTableStartFieldOffset, MemProfSectionOffset, and BinaryIdSectionOffset, which carry carry redundant information as a group. We know that MemProfSectionOffset == HashTableStartFieldOffset + 8, BinaryIdSectionOffset == HashTableStartFieldOffset + 8, etc. Also, the details of the header format are encapsulated in the new member functions, away from InstrProfWriter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants