David,<br><br>I think my explanation is not clear, my front-end did NOTt generate 'llvm.memcpy' it generate LL code that after use of LLVM 'opt' get transformed by 'loop-idom' pass into an 'llvm.memcpy' for an overlapping loop:<br>
<br>static void<br>t0(int n)<br>{<br>    int i;<br>    for (i=0; i<n; i++)<br>    result[i+1] = result[i];<br>}<br><br>Then 'llc' expanded llvm.memcpy into a sequence of load/store that where performed out-of-order and thus the final code was incorrect.<br>
So to sumarize, BUG was not in my front-end, it was in LLVM 'opt' loop-idom pass, it seems now fixed into 3.0. However I think I would be a good idea to add more control from command line on pass we want to disable.<br>
<br>Best Regards<br>Seb<br><br><div class="gmail_quote">2011/12/8 David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">> For instance, I figured out that loop-idiom pass has a BUG in<br>
> LLVM 2.9, a llvm.memcpy is generated for an overlapping memory region and<br>
> then x86 backend reorder loads/store thus generating a BUG.<br>
<br>
</div>Just for the record it seems this is a bug in your frontend, not in<br>
the LLVM backend. The memcpy intrinsic, like the standard memcpy<br>
function, requires that the regions be non-overlapping:<br>
<a href="http://llvm.org/docs/LangRef.html#int_memcpy" target="_blank">http://llvm.org/docs/LangRef.html#int_memcpy</a> By violating this<br>
contract it's possible you'll encounter all sorts of issues in other<br>
passes too.<br>
<span class="HOEnZb"><font color="#888888"><br>
- David<br>
</font></span></blockquote></div><br>