<div dir="ltr">Sounds like a potential optimization LLVM could perform, sure.</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 29, 2018 at 12:12 AM Markus Lavin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Does (or should) LLVM make any attempt to optimize the placement of llvm.lifetime.start and llvm.lifetime.end intrinsics?<br>
Considering the example below (where the pointer argument to function bar ends up being marked as nocapture in IR) the stack usage is twice of what would be necessary since the lifetime markers for mem1 and mem2 indicate that they are both live at the same time. The markers seem to remain where they were placed by clang while I naively expected that opt would try to adjust them to allow for better stack coloring.<br>
<br>
#define LEN 512<br>
<br>
void bar(__attribute__((noescape)) int *p)  ;<br>
<br>
int foo(void)<br>
{<br>
  int sum1 = 0, sum2 = 0;<br>
<br>
    int mem1[LEN];<br>
    bar(mem1);<br>
    for (int i = 0; i < LEN; i++)<br>
      sum1 += mem1[i];<br>
<br>
    int mem2[LEN];<br>
    bar(mem2);<br>
    for (int i = 0; i < LEN; i++)<br>
      sum2 += mem2[i];<br>
<br>
  return sum1 + sum2;<br>
}<br>
<br>
-Markus<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>