[PATCH] D115973: [llvm-profgen] Support symbol loading for debug fission

[James Henderson via Phabricator via llvm-commits]

jhenderson added a comment.

In D115973#3332310 <https://reviews.llvm.org/D115973#3332310>, @wenlei wrote:

>> But, yeah, if all the tools we have at the moment don't make for a moderately readable textual form, I wouldn't fundamentally object to checked in object files and source code/repro steps. Possible that the missing element right now is textual/readable dwp support, so maybe that's the limit/justification for using checked in binaries for this issue.
>
> Agreed with @dblaikie.
>
> IIUC the reasons/goals yaml was suggested are: 1) human readable, editable test; 2) smaller in file size. But it turns out in this particular case for dwo/dwp, yaml achieves neither of the two. I understand that there's an eventual state we want to be in, but it has a dependency on better tooling support which doesn't exist yet.
>
> Given what we have right now, why do we still want to push for yaml in this particular case as it achieves none of the two goals? I think it makes more sense to go with binary for this case, and we can regenerate test inputs when yaml tool has better support - better means actually achieving its goals.

As noted above, the file size issue isn't about the physical size on disk of the file in the checked out testsuite, but rather the potentially long-term impact on the .git folder size. This latter impact grows significantly every time the file gets modified, as I understand it (caveat: I haven't researched this and am only going on what others have told me), as the entire file is stored there, rather than a diff. Based on the sizes specified above, it would only take approximately 2 later updates to the binary to ensure it has a permanent impact on repo size that is greater than the YAML file does, even if only a single byte has changed. You'd also still need to check in source and instructions to allow regenerating the binary in the future (this latter point is required regardless of the approach is needed, of course, until tooling is sufficiently good. One advantage with the YAML approach is that you can store this source and instructions in the same file, rather than separate, where you coudl end up with a dead references (e.g. the binary is later replaced with a hand-crafted YAML, whilst the source and instructions weren't deleted).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115973