<div dir="ltr"><div>Using one llvm-profdata binary per-version is what we do today where our infrastructure scripts read the header from each profile, check the version and pick up the corresponding llvm-profdata binary. The challenge is mostly the overhead of managing these binaries and dispatching to the appropriate one based on the raw profile version (as opposed to simply taking all raw profiles and passing them to a single llvm-profdata binary which is what we used to do in the past).</div><div><br></div><div>I agree that having the ability to drastically change the format is very valuable and it's definitely something I'd want to preserve. What I envisioned is rather than trying to support multiple versions inside the existing RawInstrProfReader class, we could have multiple classes and dispatch to the appropriate one based on the version. So essentially implementing what we do in our downstream scripts, but directly inside the llvm-profdata tool.<br></div><div><br></div><div>The biggest advantage, aside from simplifying our own infrastructure, is the fact that this logic could be reused across different llvm-profdata users, but I don't know if there are other users that have the same issue. The disadvantage is mostly the increased complexity compared to the existing implementation and potentially some code duplication.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 24, 2021 at 1:38 PM Vedant Kumar <<a href="mailto:vsk@apple.com">vsk@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Aug 24, 2021, at 8:24 AM, Xinliang David Li <<a href="mailto:davidxl@google.com" target="_blank">davidxl@google.com</a>> wrote:</div><br><div><div dir="ltr"><div dir="ltr"><div style="font-family:monospace;font-size:small"><span style="font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)">On Mon, Aug 23, 2021 at 10:52 PM Petr Hosek <<a href="mailto:phosek@google.com" target="_blank">phosek@google.com</a>> wrote:</span><br></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">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></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><blockquote type="cite"><div><div dir="ltr"><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"><div><br></div><div>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><br></div><div 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 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"><div><br></div><div>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><br></div><div 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></div>+ 1</div><div><br></div><div>vedant</div></div></blockquote></div></div>