<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 24, 2021, at 8:24 AM, Xinliang David Li <<a href="mailto:davidxl@google.com" class="">davidxl@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family: monospace; font-size: small;"><span style="font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)" class="">On Mon, Aug 23, 2021 at 10:52 PM Petr Hosek <<a href="mailto:phosek@google.com" class="">phosek@google.com</a>> wrote:</span><br class=""></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">Currently, while IndexedInstrProfReader provides backwards compatibility for indexed profile format, RawInstrProfReader only supports the current version of raw profile format. Has support for older raw profile format versions in RawInstrProfReader ever been considered?</div></blockquote></div></div></div></blockquote><div><br class=""></div><div>Justin (cc'd) once explained to me that a key motivating factor for splitting up the raw and indexed profile formats was to free the runtime from back-compat concerns.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div class=""><br class=""></div><div class="">The reason why I'm asking is that we collect code coverage from both C++ and Rust, but since Clang and Rust toolchains use different version on LLVM, we need to match each profile with a corresponding llvm-profdata binary which has been increasing the complexity of our infrastructure quite a bit. </div></div></blockquote><div class=""><br class=""></div><div class="gmail_default" style="font-family: monospace; font-size: small;">Is it possible to save one reader binary per raw format version? What is the challenge of matching up versions with the reader binary?</div><div class="gmail_default" style="font-family: monospace; font-size: small;"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Using the same llvm-profdata tool would simplify things a lot but would require backwards compatibility support in RawInstrProfReader. Would that be desirable?</div></div></blockquote><div class=""><br class=""></div><div class="gmail_default" style="font-family: monospace; font-size: small;">Current scheme for raw format allows fast pace change and innovation. It also allows quite drastical format change. Losing that capability would be undesirable. Before pursuing this path, the benefit needs to outweigh the cost.</div></div></div></div></blockquote><div><br class=""></div>+ 1</div><div><br class=""></div><div>vedant</div></body></html>