[llvm] [StaticDataLayout][PGO]Implement reader and writer change for data access profiles (PR #139997)

[via llvm-commits]

SharonXSharon wrote:

> Tagging @SharonXSharon @ellishg .
> 
> My understanding of memory profile guided data symbols ordering (https://discourse.llvm.org/t/rfc-profile-guided-static-data-partitioning/83744/4) is that iPGHO binaries produces the profiles in [raw MemProf format](https://github.com/llvm/llvm-project/blob/2dd6a8c35a79710273bb98da8729ec6dea251998/llvm/tools/llvm-profdata/llvm-profdata.cpp#L3285-L3294). Could you share more about how the profile representation (and/or) iPGHO change look like in raw MemProf (e.g., a minimal draft PR or whatever makes the sharing easier), and how the profile is used by compiler?
> 
> This PR adds data access profiles in [indexed MemProf format](https://github.com/llvm/llvm-project/blob/2dd6a8c35a79710273bb98da8729ec6dea251998/llvm/tools/llvm-profdata/llvm-profdata.cpp#L3303-L3307), and compiler consumes it by reading indexed MemProf out of an [indexed FDO profile](https://llvm.org/docs/InstrProfileFormat.html#indexed-profile-format). Raw memprof remains unchanged. How would it interact with the iPGHO-based data symbol ordering work on your side?

Hi Mingming,
We are actually dumping the binary access profiles in a separate raw profiles at this moment, as we haven't really figured out a good way to integrate into the existing raw memory profile format. 
The raw profile we are dumping are in this format, 

```
/*
  The format of the binary access profile:
  // header
  BinaryAccessHeader header;
  // segment info
  SegmentEntry entry1;
  SegmentEntry entry2;
  ...
  // memblock addresses
  u64 MemBlockAddress1;
  u64 MemBlockAddress2;
  ...
  // end

BinaryAccessHeader is defined in MemProfBinaryAccessData.inc
PACKED(struct BinaryAccessHeader {
  uint64_t Magic;
  uint64_t Version;
  uint64_t TotalSize;
  uint64_t SegmentOffset;
  uint64_t NumSegments;
  uint64_t MemAddressOffset;
  uint64_t NumMemBlockAddresses;
});
SegmentEntry is defined in MemProfData.inc
  struct SegmentEntry {
  uint64_t Start; // segment start address
  uint64_t End;   // segment end address
  uint64_t Offset;  // binary offset at runtime
  uint64_t BuildIdSize;
  uint8_t BuildId[MEMPROF_BUILDID_MAX_SIZE] = {0};
#define MEMPROF_BUILDID_MAX_SIZE 32ULL
*/
```

W.r.t usage of the profiles, as a first step, we translate (map back) the addresses in the raw profile to symbol names (we use 8 byte as the memblock granularity to have a better, more precise mapping) and then pass the symbol names as a order file to the linker, i.e. lld takes -order_file. Note that for cstrings, we pass the hashes of the cstring literal in the order file, I am upstreaming that part in https://github.com/llvm/llvm-project/pull/140307 . Our goal is mainly to improve mobile app startup performance by reducing page faults. 

In fact, for the purpose of upstreaming the binary access profile we implemented, do you and @teresajohnson have any suggestions on how to integrate the binary access profile above into the existing raw profile format? Or is it actually better to make it separate as we are doing? 
Thanks!
Sharon 



https://github.com/llvm/llvm-project/pull/139997