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

[James Henderson 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.
----------------
jh7370 wrote:

> 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).

Correct, though it's not about compilation time as I understand it and rather about being able to do various linker operations such as section section deduplication and garbage collection. Note that this isn't free in itself, because the every section needs a section header in the intermediate ELF object, which takes time to write and read. This is one of those speed/size etc trade-offs that exist throughout file formats.

On a side-note, my original half idea which won't actually work was that you'd need 4 sections in your example and more generally N+2, where N is the number of functions. You'd need obviously one section per function, but also a separate header AND a separate tail section. The main difference to what you've got above is that the header and tail sections need to be unique from each other, otherwise they'd be turned into a single section by the compiler and the sizOn a side-note, my original half idea which won't actually work was that you'd need 4 sections in your example and more generally N+2, where N is the number of functions. You'd need obviously one section per function, but also a separate header AND a separate tail section. The main difference to what you've got above is that the header and tail sections need to be unique from each other, otherwise they'd be turned into a single section by the compiler and the size calculation wouldn't work. Once upon a time, I tried this same idea for DWARF sections (see my [LLVM lightning talk](https://www.youtube.com/watch?v=0y6TlfFhCsU) on fragmenting DWARF), although that technique didn't work due to existing limitations in the DWARF file format. There are also other issues with this approach that are not fundamental, but I believe means it won't work without other MC/linker/ELF improvements. I can think of two I ran into:

- When some sections with the same name have SHF_LINK_ORDER and others don't, LLD orders all the sections with that flag first, in the order of their corresponding functions (aside you'll want to mark the group members with this SHF_LINK_ORDER flag in the same manner as non-group ones), then those without the flag. Since the header and tail sections shouldn't have the flag (they're not associated with any particular function), they'll end up getting ordered by the linker after the rest of the sections, which defeats their purpose. What we'd actually need is some way of marking them with "put first in module" and "put last in module", whilst avoiding mixing entries from other modules in between them. This theoretically could be achieved by new section flags, but to my knowledge those flags don't currently exist. There might have been changes in LLD in this area (perhaps treating sections with SHF_LINK_ORDER but no associate section differently), but if so, I don't know what they are.
- I had some issues with either MC or LLD (I forget which) regarding the relocation between the start and end labels for the size field. Again, this isn't an insurmountable thing, but if it's still an issue might require more changes in the tools.

> 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?

Yes, this is my revised suggestion as an alternative. This may not be ideal, because it impedes size reductions through gc-sections/COMDAT deduplication etc as it leaves dead entries in the data.

Whether you adopt either of these approaches or stick with the original design really needs to be a decision that you as clients of the functionality make. Keep in mind that having more data will make it slower to read and write the data. Functionality like gc-sections can help improve this, at a cost about what the section format might look like.

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