<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Sorry for the spam. I think my mailer
screws up badly.<br>
<br>
Frank<br>
<br>
<br>
On 06/03/2015 06:22 PM, Frank Winter wrote:<br>
</div>
<blockquote cite="mid:556F7E3D.7060109@jlab.org" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix"><tt>Ok, I will do some code reading</tt><tt>;</tt><tt>
</tt><tt>t</tt><tt>he reroll pass seems seems a good starting
point.</tt><tt><br>
</tt><tt><br>
</tt><tt>Renato, thanks for the hint that this is actually a
loop pass! You're right that it's not always beneficial to
roll things up. However in this particular case I don't worry
about insisting to roll the code into a loop no matter what,
i.e. not looking at heuristics etc. In the given application
it will always be beneficial to roll it, this is an a priori
assumption</tt><tt>.</tt><tt> (the example I posted is far
smaller than what the application generates).</tt><tt><br>
</tt><tt><br>
</tt><tt>All functions are generated at runtime with the builder
(I am not coming from </tt><tt>a higher level language</tt><tt>).
Thus, I could embed the whole function in a loop with one
iteration. I will probably try this, just to see what the
reroll pass thinks about it.</tt><tt> It will not solve
everything. In real world code the code junks can become quite
large (over 1000 instructions) and I doubt tha<br>
</tt><tt><br>
</tt><tt>There's one</tt><tt> more thing.</tt><tt> </tt><tt>The
resulting loops will have high iteration counts so that it
would make sense to use all available CPU cores and distribute
the iterations among the cores. As far as I can see threading
must be taken care of 'outside of the LLVM IR', right? Coming
from the shown code</tt><tt>, </tt><tt>I would need an
mechanism that modifies the starting and ending iteration of
the loop and exposes those as arguments to the function,
right? Aka,</tt><tt><br>
</tt><tt><br>
</tt>
<pre wrap="">define void @vec_plus_vec(int %start_iteration, int %end_iteration, float* noalias %arg0, float* noalias %arg1, float* noalias %arg2) {
entrypoint:
and then call the function from each thread with thread number matching start/stop parameters.
Does anyone see any other solution to threading than this?
Thanks,
Frank
</pre>
<br>
<br>
<br>
<br>
On 06/03/2015 04:28 PM, Philip Reames wrote:<br>
</div>
<blockquote cite="mid:556F6378.3010305@philipreames.com"
type="cite"> <br>
<br>
On 06/03/2015 01:13 PM, Renato Golin wrote: <br>
<blockquote type="cite">On 3 June 2015 at 19:57, Benjamin Kramer
<a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:benny.kra@gmail.com"><benny.kra@gmail.com></a>
wrote: <br>
<blockquote type="cite">There's a loop reroll pass in LLVM
trunk that should do exactly this transformation. <br>
</blockquote>
Though that's a loop pass (runOnLoop). What you could do is
add a <br>
previous pass that would recognize the pattern and create a
loop of 1 <br>
iteration around the code and then run the reroll pass. <br>
</blockquote>
This sounds like we should need a separate pass which forms
loops from straight line code. I would strongly suggest only
forming loops when you can find at least two iterations. We can
probably share most of the code with the existing reroller, but
the wrapper pass needs a slightly different interface. <br>
<blockquote type="cite"> <br>
If your pattern recognition is too good, it'll be redundant
with the <br>
reroll pass, so I'm not sure how to do that without
duplicating effort <br>
or destroying the IR (in case you're wrong). Adding
1-iteration loops <br>
to all functions won't work either. You'll have to balance the
<br>
heuristics and make the pass optional, maybe with a pragma to
help the <br>
compiler. <br>
<br>
cheers, <br>
--renato <br>
_______________________________________________ <br>
LLVM Developers mailing list <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a> <br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
<br>
</blockquote>
<br>
_______________________________________________ <br>
LLVM Developers mailing list <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a> <br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
----------------------------------------------
Dr Frank Winter, Staff Scientist
Thomas Jefferson National Accelerator Facility
12000 Jefferson Ave, Newport News, 23606, USA
+1-757-269-6448, <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:fwinter@jlab.org">fwinter@jlab.org</a>
----------------------------------------------</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
----------------------------------------------
Dr Frank Winter, Staff Scientist
Thomas Jefferson National Accelerator Facility
12000 Jefferson Ave, Newport News, 23606, USA
+1-757-269-6448, <a class="moz-txt-link-abbreviated" href="mailto:fwinter@jlab.org">fwinter@jlab.org</a>
----------------------------------------------</pre>
</body>
</html>