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

[via llvm-commits]

WenleiHe wrote:

> Ack. It's definitely a significant size overhead, but if there are no hard limits, I think it might be hard to justify using something as specific as a function-level dynamic instruction count as a new member for the BBAddrMap. 

In our case, users are very sensitive to binary size increase. While there is no explicit limit, the increase in size is deal breaker for many of our users. 

> We used an offline tool because we don't really know yet what works in terms of cost modeling, so putting something directly in the compiler didn't make too much sense for experimentation. The info is definitely available in the compiler, but we found it easier for our workflows to have an offline tool do the modeling based on the information rather than trying to do it in the compiler. llvm-cm isn't used for model training currently.

You're right that it doesn't make sense to commit some experimental stuff. However our use case is different, and this is not experimental. So our goal here isn't really accurate cost modeling. What we need is just simple dynamic instruct count aggregation -- the goal is to tell users instruction count change purely from any user source change (with very limited optimization), and it's not for evaluating compiler optimization. Think of it as a simple, rough, directional signal for developers, and it could be surfaced through IDE or phabricator. 

We want to keep it simple so developer can reason about it easily. We don't want the complexity from llvm-cm, and we also can't depend on an out-of-tree google tool. 

I hope that explains why we need this change. 

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