[llvm] [BasicBlockSections] Propose a staleness detection method, checking the func cfg node num (PR #133244)

[Jinjie Huang via llvm-commits]

Jinjie-Huang wrote:

> Could you say more about the design choice here of just using node count? Looks like storing the hash of the entire CFG in some manner would me more meaningful. You don't want to be too sensitive to IR changes, so hashing the entire IR might be too much.

Thank you for your response. I believe the biggest advantage of currently using only the CFG node count is that it is sufficiently "lightweight," utilizing existing information without requiring extensive modifications. 
Based on our observations, when there are changes in mid-level optimization results (especially with changes in FDO profiles), it almost always comes with  CFG node count change (perhaps 95%). In such scenarios, this approach can effectively stop wrong reordering.
Compared to the precision of hashing the entire CFG (such as using indirect-call count, CFG edge count, and CFG-bb-index-CRC32 information as in PGO), we might **value more the basic requirement of preventing performance degradation in Propeller** (which is more engineering iteration-friendly). The results indeed reflect this, so I believe this level of verification might already be "enough" for current use.

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