<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 14, 2014 at 8:29 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">On 02/14/2014 05:42 PM, Hal Finkel wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
1. Does our "llvm.mem.parallel_loop_<u></u>access" metadata represent the implied<br>
semantics, which seem to cover "vector dependencies" but not loop-carried<br>
dependencies<br>
</blockquote>
<br></div>
IIRC the end result from the previous discussion was that<br>
as it's not in general possible to know which are "compiler proven dependencies"<br>
(and which only "assumed" due to, e.g., not having a smart enough AA),<br>
we can might as well assume ivdep to have the "embarrassingly parallel<br>
loop" semantics the llvm.mem.parallel_loop_access was intended originally<br>
to denote. Seems Intel came to the same conclusion?<br></blockquote></div><br></div><div class="gmail_extra">The implementation we have is experimental, so we just used "llvm.mem.parallel_loop_access" as it looked as the best thing available. Frankly, not much thought went into this.<br>
<br>Andrey<br><br></div></div>