wlei-llvm wrote: > We will need some protection against accidentally consuming old profile with > new toolchain and vice versa. The cost of investigating mysterious perf > regression can be high and we'd rather simply error out in those cases. Maybe > consider some flag for `SecProfSummaryFlags` > Agreed with this concern. To do this, we probably also need a flag in the binary, because otherwise if we use the new toolchain for prof-gen but the binary built on the old toolchain, we then would generate a profile with this flag on but the order is the old one. My understanding is the (probe) version of profile should line up with the version of the binary. Maybe make this more general, we can introduce a "pseudo_probe_version" thing, similar to instrPGO https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/ProfileData/InstrProf.h#L996 . It can be useful if we want to update other pseudo probe formats in future.
> (also wondering if this needs to be per-function flag since technically some > function/module can be compiled with old order while others with new order). This seems very complicated, supposing you meant it's mixed compiled case(some objects files are built on old toolchain and some are on new toolchain), then in profile generation time, it's hard to know which order the function uses. That requires some function level version thing.. maybe add version to `pseudo_probe_desc` which is function-level and encode the version. > Can we gauge perf benefit of mixed order encoding? i.e. profile an old source > rev (several weeks ago?) with both probe order, and build with new source rev > using that old profile, then see how old vs new order compare in terms of > perf and efficacy with incremental PGO. Yes, I saw some perf wins using the new order, it's not as easily measurable as the call anchor, as you said, I had to use a old rev to run profile collection using the new order. I will show you the results offline. https://github.com/llvm/llvm-project/pull/75092 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
