Currently the logic to do value profiling (VP) for (1) indirect function calls and (2) memory intrinsic length parameter is scattered in PGOInstrumentation.cpp.
If we are to extend the scope of VP (e.g. loop trip-count profiling), there’s an opportunity to refactor things out as follows:
- Encapsulate each kind of VP in it’s own class (or logical unit). The class will be responsible for deciding what to value profile and when (see next point).
- Define an interface that each class has to adhere to and a data-type describing the exact information that each VP class needs to provide/compute.
- Having done (1) and (2), we can decouple the logic for deciding what to value-profile from the “mechanical” logic of doing the instrumentation and annotation.
Some of the benefits that I see in doing the above is:
Easier to add new VP kinds in the future (I’m planning to do so).
Less version control conflicts for code downstream.
I posted this patch for review: https://reviews.llvm.org/D67920
Please let me know what you think?
IBM Canada Lab