<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><p><span style='color:#1F497D'>Hi,<o:p></o:p></span></p><p><span style='color:#1F497D'>Note: I'm not in any way associated with the GSoC infrastructure in the LLVM community; these are purely personal thoughts.<o:p></o:p></span></p><p><span style='color:#1F497D'>| </span>I'd like to propose a GSoC project with the goal of implementing a library for profiling instrumentation of LLVM IR.<o:p></o:p></p><p><span style='color:#1F497D'>| </span>Currently, my idea is make the library general enough to insert arbitrary code or a call to a void(*)(void) before or after reads/writes from a specified variable or in the prologue/epilogue of a specified function.<o:p></o:p></p><p><span style='color:#1F497D'>| </span>I would like to build more than this on top of the general interface, but a lot of profiling specific code is also above LLVM's level, such as getting timestamps to measure time spent in a function or outputting results to a file (like gcc -pg).<o:p></o:p></p><p><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>One of the things that is obviously present in putting in many timing points is a "Heisenberg-type effect": if you check too frequently you're perturbing the program (either/both in terms of inhibiting optimizations and changing run-time behaviour). So one thing that I think would be very interesting would be a way to specify which useful positions to put timing points on (not everywhere, but not just at function level granularity). For example, it might be interesting to put timing points before and after loops (or perhaps just outermost loops). Of course this is a very vague notion which would need firming up significantly before beginning. For example, in trying to determine which formulation has the best cache behaviour adding lots of timing points may provide enough extra instructions that a smart out-of-order processor could hide the issues that would manifest in the non-instrumented code. This sort of stuff would, for me, be most interesting if it was done at the LLVM rather than clang level, since not every interesting program is written in a dialect of C.<o:p></o:p></span></p><p><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Now I don't know if either this is of interest to other members of the LLVM community or this sort of non-known stuff, with a consequently greater uncertainty is suitable for a GSoC project; these are more my thoughts about profiling instrumentation in general.<o:p></o:p></span></p><p><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Cheers,<o:p></o:p></span></p><p><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Dave<o:p></o:p></span></p></div></body></html>