[llvm] [PGO] Add `llvm.loop.estimated_trip_count` metadata (PR #148758)

[Joel E. Denny via llvm-commits]

================
@@ -316,28 +318,73 @@ LLVM_ABI TransformationMode hasDistributeTransformation(const Loop *L);
 LLVM_ABI TransformationMode hasLICMVersioningTransformation(const Loop *L);
 /// @}
 
-/// Set input string into loop metadata by keeping other values intact.
-/// If the string is already in loop metadata update value if it is
-/// different.
-LLVM_ABI void addStringMetadataToLoop(Loop *TheLoop, const char *MDString,
-                                      unsigned V = 0);
-
-/// Returns a loop's estimated trip count based on branch weight metadata.
-/// In addition if \p EstimatedLoopInvocationWeight is not null it is
-/// initialized with weight of loop's latch leading to the exit.
-/// Returns a valid positive trip count, saturated at UINT_MAX, or std::nullopt
-/// when a meaningful estimate cannot be made.
+/// Set the string \p MDString into the loop metadata of \p TheLoop while
+/// keeping other loop metadata intact.  Set \p *V as its value, or set it
+/// without a value if \p V is \c std::nullopt to indicate the value is unknown.
+/// If \p MDString is already in the loop metadata, update it if its value (or
+/// lack of value) is different.  Return true if metadata was changed.
+LLVM_ABI bool addStringMetadataToLoop(Loop *TheLoop, const char *MDString,
+                                      std::optional<unsigned> V = 0);
+
+/// Return either:
+/// - The value of \c llvm.loop.estimated_trip_count from the loop metadata of
+///   \p L, if that metadata is present and has a value.
+/// - Else, a new estimate of the trip count from the latch branch weights of
----------------
jdenny-ornl wrote:

> Ah, so the idea is to have the implementation here in this PR as a stop-gap, correct?

That sounds right for one side of it: some passes need to be adjusted to maintain this metadata properly.

But I am also thinking of any existing test cases and other use cases that don't strictly follow the approach we envision (i.e., add branch weight metadata to every loop, and then run pgo-estimate-trip-counts to add all estimated trip count metadata).  For example:
1. What if there are already branch weights and opt is called without pgo-estimate-trip-counts but with passes that call getLoopEstimatedTripCount or setLoopEstimatedTripCount?
2. When, e.g., debugging a broken pass, would running pgo-estimate-trip-counts be useful for fixing up just the loops that have missing estimated trip counts (either metadata or just values)?

For now, I'd like to keep things flexible, and LLVM_DEBUG can tell us when usage doesn't fit the ideal vision.

> So subsequent PRs would fix passes to write the metadata, and eventually `getLoopEstimatedTripCount` would just fetch metadata?

Possibly, depending on at least the following:
1. Who will identify and fix all such passes?  I'm not eager to keep putting effort into estimated trip counts right now.  First, some in the community think estimated trip counts are not worthwhile generally.  Second, I came here to work on block frequency issues, and the goal of this PR is to move estimated trip counts out of the way of that effort. 
2. As we work with the new metadata, will the greater flexibility of the current PR benefit use cases like those I mentioned above?

> 
> Maybe also add to the TODO in `getLoopEstimatedTripCount` that "...and rely solely on metadata" or smth?

Sure, I can add a note there.

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