[llvm] [llvm]Add a simple Telemetry framework (PR #102323)

[James Henderson via llvm-commits]

https://github.com/jh7370 commented:

I've gone through the implementation, but run out of time to look at the tests today. I'll look at those more next week, if I can. If there are any elements I've missed replying to in the non-test parts of this PR, please call them out, as I've left this too long to be hot on the whole conversation.

I've spent over 2 hours looking at this today, writing up thoughts and comments and generally thinking about the design and how it might fit into the upstream codebase. My goal from this would be to have something that would allow us (Sony) to reduce our downstream patch count related to implementing telemetry in clang. lld and various other LLVM tools, so that we get fewer merge conflicts. I imagine other vendors have similar desires. I acknowledge that there are likely to always be places where we'll have event dispatching patches downstream, because we are collecting data that isn't generally desired. However, I reckon there may be some places that are broadly more applicable. In particular, launching telemetry and some basic events like measuring the time some things take seem like areas that could do with some upstream hooks.

I realised that in order for these upstream hooks to be able to exist in upstream tools, we need to have a concrete implementation in some form or other. That concrete implementation doesn't have to do anything, but we can't have pure abstract classes in use by concrete tools, nor can we have undefined methods to create these classes. When I say concrete implementation, I'm not necessarily talking about a _useful_ implementation. Rather, I actually think we could have a "this does nothing unless the downstream code does something else" bit of code. Perhaps something like the Telemeter class has a single method that says `readVendorConfig`, which does nothing in the upstream implementation, but vendors fill it in with their own implementation which configures the right `Destination` instance etc. I feel like I'm pulling at a thread here that might produce a widely useful solution, but I'm out of time to pull it further. Hopefully it might spark some more ideas going forwards.

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