<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 30, 2014 at 9:04 AM, RAVI KORSA <span dir="ltr"><<a href="mailto:ravi.korsa@gmail.com" target="_blank">ravi.korsa@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div>is there any guarantee that the nvptx intrinsic "llvm.nvvm.barrier0" will not be moved around by opt ?<br>In other words, can I expect all the instructions above "llvm.nvvm.barrier0" to remain above it and those below it to remain below, after all the opt passes are run ?<br></div></div></div></blockquote><div><br></div><div>AFAIU, yes. Here's the definition:</div><div><br></div><div>  def int_nvvm_barrier0 : GCCBuiltin<"__nvvm_bar0">,</div><div>      Intrinsic<[], [], [IntrNoDuplicate]>;</div><div><br></div><div>Note that IntrNoDuplicate is the only intrinsic attribute. It has no other attributes (like IntrNoMem) that would make it permissible for LLVM optimizations to reorder things around it. By default, the optimizers would not do this for function calls; only if these function calls are marked with special attributes that permit this.</div><div><br></div><div>Eli</div><div><br></div></div></div></div>