<font face="Verdana,Arial,Helvetica,sans-serif" size="2"><div>Hi.</div><div>Currently the logic to do value profiling (VP) for (1) indirect function calls and (2) memory intrinsic length parameter is scattered in PGOInstrumentation.cpp. </div><div>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:</div><div> 1. 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).</div><div> 2. 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.</div><div> 3. 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.</div><div><br></div><div>Some of the benefits that I see in doing the above is:</div><div> 1. Easier to add new VP kinds in the future (I'm planning to do so).<br></div><div> 2. Less version control conflicts for code downstream.</div><div><br></div><div>I posted this patch for review: <a href="https://reviews.llvm.org/D67920">https://reviews.llvm.org/D67920</a><br></div><div>Please let me know what you think?</div><div><br></div><div>Wael Yehia</div>Compiler Development<br>IBM Canada Lab<br><a href="mailto:wyehia@ca.ibm.com">wyehia@ca.ibm.com</a></font><BR>