llvm dev - Sep 2019 - [RFC] Refactor Value Profiling into a plugin based oracle and create a well defined API for the plugins.

<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>

Looks like something useful. I have inserted myself as a reviewer, and we
can bring discussion there.

David


On Mon, Sep 23, 2019 at 11:54 AM Wael Yehia via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi.
> 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:
>  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).
>  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.
>  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.
>
> Some of the benefits that I see in doing the above is:
>  1. Easier to add new VP kinds in the future (I'm planning to do so).
>  2. 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?
>
> Wael Yehia
> Compiler Development
> IBM Canada Lab
> wyehia at ca.ibm.com
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190923/e1530843/attachment.html>