[llvm] [SHT_LLVM_BB_ADDR_MAP] Add a new PGOAnalysisMap feature to emit dynamic instruction count (PR #119303)

[Lei Wang via llvm-commits]

wlei-llvm wrote:

Sorry for the late reply(was on a long holiday leave) and thanks for the comments.

> It seems that this feature uses the `SHT_LLVM_BB_ADDR_MAP` infrastructure for function address mapping for a per-function metadata with no need for basic block address mapping. While it might be tempting to reuse the infrastructure for this purpose (probably because of interaction with pgo-analysis-map), I think it may overload the parsing and emitting code in the long run.

Let me clarify further, I hope to explain this feature should have very little impact on future maintenance. 

The new feature(Dynamic-instruciton-count) should be a general and stable feature. It’s not experimental, and the definition is straightforward ,i,e. the total count of all the instructions within a function(think of linux perf tool, it provides the Instructions event which offers different insights compared to the Cycles event), it’s architecture-independent and should rarely require changes. And the code is small, just needs one field encoding/decoding.  Regarding the place to implement, yes, as you said, I feel it’s strongly relevant to PGO feature/pgo-analysis-map. Like the function-entry-count, which also doesn’t need bb addressing mapping, and we will use https://github.com/llvm/llvm-project/pull/114447 to skip BB info to save the size. 

> The alternative is to define a new [extension](https://llvm.org/docs/Extensions.html) and implement the parsing/emitting logic separately. Since your structure is basically a map from function addresses to counts, it shouldn't be too hard to implement, though I agree you would need to add code in different places (ObjectYaml, Object, Codegen). @jh7370 may have an opinion here.

So I hope we can extend this to `pgo-analysis-map` but I’m also open to this option, that’s indeed separated from`BB_ADDR_MAP` and  I agreed it shouldn’t be hard given I can just mimic BB_ADDR_MAP. However, my question is whether this single feature big enough to be as a new extension? Though if we go this way, I would make it more general use(perhaps name it SHT_LLVM_PGO_FUNC_ANALYSIS_MAP indicating it's for all function-level PGO feature). 

@jh7370  Let me share more context with you. 

We are working on a new feature(dynamic-instruciton-counts, the total PGO counts for all instructions within a function) and its emission. It will be used as a indicator for developer to tell instruction count changes from source code changes without running the binary.  As it's a PGO related feature, we initially planned this to be an extension to the existing `pgo-analysis-map` in SHT_LLVM_BB_ADDR_MAP. But as @rlavaee pointed out, this feature emitted a count number per-function level and it doesn't need the BB address mapping, so it may overload BB_ADDR_MAP. Alternatively, IIUC, @rlavaee suggested to define a new [extension](https://llvm.org/docs/Extensions.html) to implement function-level PGO analysis features. To do this, it will add a new section and code to ObjectYaml/ llvm-readobj/ Codegen, so I'd like to hear your opinion before we start the implementation. Thanks in advance!








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