<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 7, 2013 at 6:55 PM, Pekka Jääskeläinen <span dir="ltr"><<a href="mailto:pekka.jaaskelainen@tut.fi" target="_blank">pekka.jaaskelainen@tut.fi</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Nadav,<div class="im"><br>
<br>
On 02/07/2013 07:46 PM, Nadav Rotem wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Pekka suggested that we add two kind of metadata: llvm.loop.parallel<br>
(attached to each loop latch) and llvm.mem.parallel (attached to each memory<br>
instruction!).  I think that the motivation for the first metadata is clear -<br>
it says that the loop is data-parallel. I can also see us adding additional<br>
metadata such as llvm.loop.unrollcnt to allow the users to control the unroll<br>
count of loops using pragmas. That's fine. Pekka, can you think of<br>
transformations that may need invalidate or take this metadata into<br>
consideration ?<br>
</blockquote>
<br></div>
Any pass that introduces new non-parallel memory instructions to the loop,<br>
because they think the loop is sequential and it's ok to do so. I do not know<br>
any other such pass than the one pointed out earlier, reg2mem (if the<br>
variables inside the loop body reuse stack slots). E.g., inlining<br>
should be safe. So should be unrolling an inner loop inside a parallel loop.<br>
<br>
Anyways, the fact that I do not know more of such passes to exist does not<br>
mean there isn't any. Especially when you consider there are out of tree<br>
passes in external projects that use LLVM. Therefore, the "safety first"<br>
approach of annotating the memory instructions and falling back to sequential<br>
semantics if non-annotated memory instructions are found sounds sensible to me.<br>
<br></blockquote><div><br></div><div>Another possibility would be for passes to be only-just parallel metadata aware, in that if a pass which doesn't know enough to correctly preserve parallel metadata will not do anything if it sees any parallel markers (maybe trying to find the smallest region to which this "don't run yourself" applies, maybe not). In that way the metadata is guaranteed to remain correct at the cost of missing out on some reorgranisations that are done on non-parallel-metadata code. I don't know how well this would fit in with the general philosophy of LLVM passes though.<br>
<br></div><div>(I'm also aware that we're coming at this from different directions: most people are interested in auto-parallelisation, where missing a parallelisation opportunity is just one of those unfortunate things, while I have a personal interest in DSLs which try to present LLVM code with huge "parallelise this" signs pointing at bits of it. It would be frustrating to have carefully made sure the DSL twisted things into a parallelisable form only to have parallelisation/vectorization "fall at the last hurdle".)<br>
</div><br></div>Cheers,<br>Dave<br></div><div class="gmail_extra"><br><br></div></div>