Subject: RFC: Instrumentation based profiling file libraries
Date: Wednesday 12th March 2014 22:54:16 UTC (over 4 years ago)
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.