[llvm] [SHT_LLVM_FUNC_MAP][ObjectYaml]Introduce function address map section and emit dynamic instruction count(ObjectYaml part) (PR #124332)

[Lei Wang via llvm-commits]

================
@@ -535,6 +535,27 @@ Example of BBAddrMap with PGO data:
    .uleb128  1000                         # BB_3 basic block frequency (only when enabled)
    .uleb128  0                            # BB_3 successors count (only enabled with branch probabilities)
 
+``SHT_LLVM_FUNC_MAP`` Section (function address map)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+This section stores the mapping from the binary address of function to its
+related metadata features. It is used to emit function-level analysis data and
+can be enabled through ``--func-map`` option. The fields are encoded in the
+following format:
+
+#. A version number byte used for backward compatibility.
----------------
wlei-llvm wrote:

I'm working on the implementation, but haven't gotten it to work. I have some questions:

>So the SHT_LLVM_BB_ADDR_MAP section was implemented using SHF_LINK_ORDER. It works because we create one section per function and each section is linked to exactly one function section. We also create this section late in the codegen. So we won't be affected by inlining.

For the current version, the `SHT_LLVM_FUNC_MAP ` section use the exact same way as `SHT_LLVM_BB_ADDR_MAP`([code](https://github.com/llvm/llvm-project/pull/124334/files#diff-7b2f023e629bba79730e537c687b7b5363105a20ca9eb8f85c448bb296a510bdR1123-R1139)) for the same reason(only funcs in the finial binary matter), so each functions corresponds to one section. Then from my current implementation, it seems that the header approach doesn't work to cross sections. e.g.

```
.section  .llvm_func_map,"o", at llvm_func_map
.long .func_map_end - .func_map_start
.func_map_start:
.byte 1.                  #version
.section  .llvm_func_map,"axG", at llvm_func_map,foo,comdat
  .long 8
.section  .llvm_func_map,"axG", at llvm_func_map,bar,comdat
  .long 8
.section  .llvm_func_map,"o", at llvm_func_map
.func_map_end:
```
IIUC, section `.llvm_func_map,"o", at llvm_func_map` is different to section `.llvm_func_map,"axG", at llvm_func_map,foo/bar,comdat`
so there are three separate sections and compiler doesn't combine them(compilation time). In the end, it appears only the first section contains the size(`.func_map_end - .func_map_start`) which is only 1 byte(the version), it doesn't include the data from other two COMDAT sections. That seems not correct, as header should be module level, size should be sum of all the entries' size. 

Or did you suggest we should use a single section for all functions(like using the ` .llvm_func_map,"o", at llvm_func_map`), but then that means we would lose the ability to deduplicate COMDAT section. is my understanding correct? 

> For SHT_LLVM_FUNC_MAP, we can pay the price for gc-sections (given that we win on version field deduplication). 

(If we go the single section way) Then regarding the "the price for gc-sections"  vs the price for duplicated version field, I'm wondering which one is more significant? Considering the version field is deduplicated through ([code](https://github.com/llvm/llvm-project/pull/124334/files#diff-7b2f023e629bba79730e537c687b7b5363105a20ca9eb8f85c448bb296a510bdR1123-R1139)), it's just 1 extra byte per finial binary function. On the other hand, I personally think the link_onceodr functions could have much more copies before deduplication. If we don't do deduplication, it would be the 16 bytes(func_address + dyn_inst_count for now) * num of the duplicated IR functions. Would there be more overhead from duplicated entries(If needed, I can verify this on one of our large service)?

(not expert in this area, my understanding could be completely off) Appreciate any further insights/guidances on this!



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