This is an archive of the discontinued LLVM Phabricator instance.

[InstrProf] Make the IndexedInstrProf header backwards compatible.
ClosedPublic

Authored by snehasish on Jan 27 2022, 9:17 AM.

Details

Summary

While the contents of the profile are backwards compatible the header
itself is not. For example, when adding new fields to the header results
in significant issues. This change adds allows for portable
instantiation of the header across indexed format versions.

Diff Detail

Event Timeline

snehasish created this revision.Jan 27 2022, 9:17 AM
snehasish requested review of this revision.Jan 27 2022, 9:17 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 27 2022, 9:18 AM

The refactoring looks good. However in what situation do we need to modify the main header? There might be other ways to achieve the functionality.

The refactoring looks good. However in what situation do we need to modify the main header? There might be other ways to achieve the functionality.

We discussed some alternatives offline, summarizing here:

The motivation behind this change is the desire to add another (optional) ondiskhashtable to the indexed profile format. This will hold memory profile information which will be used to guide the memory allocator [1]. However the phase ordering of memory instrumentation (envisioned to be enabled at the same time as FDO instrumentation) implies that the current "function name & CFG hash" based indexing for the existing on disk hashtable is incompatible for memprof profile data. While it may be possible to refactor out the has computation to reuse, the approach is brittle and there are unknowns along with a larger radius of potentially affected users. Adding a new field to the header allows us provision another memprof profile data section. This section will contain metadata and an on disk hash table with the profile data.

Why not use the Unused field?
Existing profiles may break, at least the compat tests in the repo have old profiles which have this field set.

Why not add indirection to the existing on disk table header?
The on disk table structure allows for metadata before the actual payload and this approach is feasible. However, it makes the logic in IndexedInstrProfReader even more complicated and harder to follow.

I'll add some more static checks to ensure that users don't inadvertently break the ordering based computation here.

[1] https://groups.google.com/g/llvm-dev/c/h1DvHguLpxU/m/yGE-zyrhAAAJ

davidxl accepted this revision.Jan 28 2022, 9:36 AM

lgtm

This revision is now accepted and ready to land.Jan 28 2022, 9:36 AM
This revision was landed with ongoing or failed builds.Feb 14 2022, 9:55 AM
This revision was automatically updated to reflect the committed changes.

This patch broke on big endian systems due to the interpretation of the FormatVersion variable. While refactoring the code, I replaced uses of the FormatVersion local variable with Header::Version in all but one check. For little endian reader and writer setup this passed since we always check the format version after a byte_swap to little endian (so in this case it was a no-op). I added a new method to the Header struct to return the format version in little endian instead of a local var. This passed all the instrprof unit tests on a local big endian setup. I would have liked to update this diff but arc got confused so if you have any comments please add them to https://reviews.llvm.org/rGa3beb34015fc. Thanks!