[PATCH] D136698: [SampleFDO] Persist profile staleness metrics into binary

[Lei Wang via Phabricator via llvm-commits]

wlei added a comment.

In D136698#3892484 <https://reviews.llvm.org/D136698#3892484>, @mtrofin wrote:

> In D136698#3883961 <https://reviews.llvm.org/D136698#3883961>, @wenlei wrote:
>
>> In D136698#3883954 <https://reviews.llvm.org/D136698#3883954>, @davidxl wrote:
>>
>>> For incremental build, are the artifacts (build logs) also cached?
>>>
>>> Anyway, I can see the usefulness of the post-build analysis case. However should we consider more general mechanism for message persistence? I will copy some folks in the review.
>>
>> Yes, this should be more general than profile staleness. Actually the other use case we have in mind is for persisting static performance proxy, which can also be used as full reward function for MLGO.
>
> (sorry for the delay) SGTM, I assume, if we want the values to be more complex, we can base64-encode them or something like that (i.e. we can evolve the format to not assume the values are ints); also, we may want to allow, at a later stage, the section to be populated with values available to the assembler - like exact MBB sizes - I don't think that'd be difficult to fit in at a later stage (some sort of callback to TargetLoweringObjectFileImpl.cpp or something like that). I'm listing these to check if there's any assumptions that such later evolution might invalidate.

Thank you for the feedback! Changed to use base64-encode for the value encoding.

> we may want to allow, at a later stage, the section to be populated with values available to the assembler - like exact MBB sizes - I don't think that'd be difficult to fit in at a later stage (some sort of callback to TargetLoweringObjectFileImpl.cpp or something like that).

I was trying to play with the later stage values, it seems current framework should be able to be extended for this feature, i,e, it's covered as long as it can emit the values to the metadata. For the MC level values(like the MBB sizes ), IIUC, it's still able to access the metadata, And later in the AsmPrinter, `TLOF.emitModuleMetadata(*OutStreamer, M);` is called in `AsmPrinter::doFinalization(Module &M){...}`, my understanding is that `doFinalization` is already the very later stage, it's after the assembling things. Please let me know if I missed anything.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136698/new/

https://reviews.llvm.org/D136698