[LLVMdev] RFC: Instrumentation based profiling file libraries

Justin Bogner mail at justinbogner.com
Wed Mar 12 15:54:16 PDT 2014


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.



More information about the llvm-dev mailing list