<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><font face="Courier New, Courier, monospace">Hi David, <br>
</font></p>
<p><font face="Courier New, Courier, monospace">Thanks for the reply
:) </font>Please see my comments inline.<br>
</p>
<div class="moz-cite-prefix">On 30/03/19 3:08 AM, David Greene
wrote:<br>
</div>
<blockquote type="cite" cite="mid:nngef6p2wf2.fsf@cray.com">
<pre class="moz-quote-pre" wrap="">preejackie via llvm-dev <a class="moz-txt-link-rfc2396E" href="mailto:llvm-dev@lists.llvm.org"><llvm-dev@lists.llvm.org></a> writes:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Are you suggesting that static analysis is much inferior than
profiling in finding "next executing function" ? I'm stuck at
deciding which one to prefer & implement during this summer project,
Could you please help me?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I suspect this is highly code-dependent. For example, it's probably
feasible to use static analysis to determine error paths, at least for
fairly well-behaved programs. A whole-program analysis might be able to
better determine such paths but that's likely too heavyweight for a JIT.
AOT could do it and use metadata to guide the JIT.
On some codes, paths within a loop may be fairly evenly distributed over
iterations while for others, execution may be highly biased toward a
few. This is probably going to be the most difficult thing to analyze
statically without a lot of context and even then it may be determined
by runtime user input and therefore unknowable statically.
</pre>
</blockquote>
Agreed, such kind of analysis requires more time which will directly
impacts the execution time of Application in JIT. Even though PGO
has extra build/instrument/run cycle I think it will generate good
representatives of real time workload. So I decided to implement
dynamic profile (instrumentation) for JIT.<br>
<blockquote type="cite" cite="mid:nngef6p2wf2.fsf@cray.com">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Also if I choose to do PGO stuff with ORC, Can I able to use most of
PGO code available for AOT with the JIT. Is there any downsides to it?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I'm sorry I can't really comment on that as I don't have much experience
with it. From what little I've looked at the instrumentation code, it
seems fairly standard, in that it tries to limit the profiling overhead
using minimum spanning tree techniques. Whether that is too heavyweight
for a JIT I can't really say. I suspect it would potentially severely
impact performance for some codes. Of course, once a path has been
determined to be hot you'd probably want to remove the instrumentation.
</pre>
</blockquote>
Idea here is not only to recompile hot functions but also compiling
them ahead of time before they actually start to execute. So I hope
that it will not be heavy weight for JIT, given that we ruled out
the static analysis approach. It would be nice to reuse many parts
of static PGO stuff here, and I will implement to profile, data
which is only useful in case of JIT.<br>
<blockquote type="cite" cite="mid:nngef6p2wf2.fsf@cray.com">
<pre class="moz-quote-pre" wrap="">
-David
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Have a great day!
PreeJackie</pre>
</body>
</html>