The frontend-driven instrumentation based profiling used for clang's
-fprofile-instr-generate and -fprofile-instr-use currently has logic for
handling its data format spread about a few different places:
1. Reading files is done in clang when -fprofile-instr-use is
specified. The logic is in CodeGen/CodeGenPGO.cpp.
2. Reading files is done by the (very preliminary) llvm-profdata tool,
which does this manually in llvm-profdata.c
3. Writing files is done in compiler-rt, which is invoked by clang's
instrumentation when -fprofile-instr-generate is specified.
4. Writing files is done in the llvm-profdata tool, again by hand.
It would be nice to consolidate as much of this as possible into a
library, so that updating the file format and ensuring correctness are
easier.
We can fairly easily solve (1), (2), and (4) by moving the logic into an
LLVM library. I would like to do this soon as a first step and to
unblock dependent work.
- None of the current LLVM libraries seem appropriate, and there is
precedent for adding simple libraries that do one thing, so a new
library seems best.
- This library could either be (A) a standalone library for reading and
writing the instrumentation based profiling format, or (B) a library
that includes readers and writers for various profiling formats.
Notably, (B) would make it a good place for a sample based profile
reader, which currently lives in lib/Transforms with its usage.
- If we go with (A), a name like Profile may be too generic, so something
more specific like InstrProfile might be better. For (B), Profile or
ProfileData seem best.
The other part of the problem, (3), has no precedent that I'm aware of.
Is there a way to include llvm libraries in compiler-rt that wouldn't
cause problems? I don't plan on addressing this in the near future, but
comments on what options are available would be appreciated.