[PATCH] D104060: Machine IR Profile

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added a comment.

@ellis

> The main challenge is storing the offset to the profile data without using dynamic relocations. This is complicated by the fact that we use comdat sections within the __llvm_mipraw section and that ELF does not seem to directly support section relative addresses. The solution is to use PC relative relocations. __start___llvm_mipraw-.Lref gives us the PC relative offset to the start of the raw section and _Z3foov$RAW-.Lref gives us the offset to the profile data for this function relative to the same PC. After we extract the map section, we can subtract these to get the value we want, the section relative raw profile data offset.
>
> (_Z3foov$RAW-.Lref) - (__start___llvm_mipraw-.Lref) = _Z3foov$RAW - __start___llvm_mipraw

I am unclear about this. Why does the `$MAP` section needs to know its relative position?

Note: if the `$RAW` symbol has a local linkage or has the hidden visibility, both an PC-relative static relocation and an absolute static relocation will lead to a `R_*_RELATIVE` dynamic relocation.
There will be no size difference in the linked image.

> We can use the same trick to encode the function address, we just need to also add the address of the raw section which can be looked up in the binary. This is useful to lookup debug info and join it with our final profile data.

A `__profd_$name` variable has a similar field referencing the function. It is used by `IPVK_IndirectCallTarget` so that indirect call target profile can be translated to function names.

In a `-no-pie`, `-pie`, or `-shared -Bsymbolic-functions` link, using a PC relative relocation does not improve size.

A non-symbolic `-shared` link can save a dynamic relocation, but I think that case may be less interesting and may not worth implementing.

  ; Note the sub constexpr
  @__profd_main = private global { i64, i64, i64*, i64, i8*, i32, [2 x i16] } { i64 -2624081020897602054, i64 742261418966908927, i64* getelementptr inbounds ([1 x i64], [1 x i64]* @__profc_main, i32 0, i32 0), i64 sub (i64 ptrtoint (i32 ()* @alias_main to i64), i64 ptrtoint ({ i64, i64, i64*, i64, i8*, i32, [2 x i16] }* @__profd_main to i64)), i8* null, i32 1, [2 x i16] zeroinitializer }, section "__llvm_prf_data", comdat($__profc_main), align 8
  
  @alias_main = private alias i32 (), i32 ()* @main
  
  define i32 @main() #0 {
    ...

For other fields of `__profd_$name`, other than the generality and mandatory value profiling (even if you don't use it) issues I mentioned in https://reviews.llvm.org/D104060#2818268 ,
I think the `$MAP` format is the same.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104060/new/

https://reviews.llvm.org/D104060