I have a question about inputs to llvm-profdata. I know that for inputs generated by llvm-profdata (or create_llvm_prof, in the case of AFDO), we bake version numbers in, so if a user tries to use a too-new profile with an older version of LLVM, they’ll get an informative error message.
Are similar error guarantees made for the use of llvm-profdata with code coverage/profile data that’s produced directly by an instrumented binary? I have a user that has profraw artifacts that could’ve been generated by one of two LLVM versions, but no convenient mechanism to tell which LLVM version the profiles came from. They’re trying to figure out whether “try one version of llvm-profdata, then the other if that exits uncleanly,” is a viable strategy for correctly handling these.
This is a situation we have in our infrastructure as well where we often process profiles produced by different compilers. The solution we use at the moment is using a separate tool that just reads the magic followed by a version from the raw profile and prints the version. @davidxl would it be acceptable to you if we implemented similar functionality as a new subcommand in the llvm-profdata tool?