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