<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 1, 2016 at 8:58 AM, Daniel Berlin via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">The existing lifetime start/end is not very well defined (by spec, or by code) in what it means, so you could have nested lifetime markers if you wanted.   If you made the spec well-defined, they would be meaningful (for loops, etc).</div><div class="gmail_extra"><br></div><div class="gmail_extra">There are a number of open bugs/complaints about lifetime markers and the fact that the scope is not well defined (the spec says "This intrinsic indicates that before this point in the code, the value of the memory pointed to by <code style="font-family:consolas,"deja vu sans mono","bitstream vera sans mono",monospace;font-size:0.95em"><span>ptr</span></code> is dead. This means that it is known to never be used and has an undefined value. A load from the pointer that precedes this intrinsic can be replaced with <code style="font-family:consolas,"deja vu sans mono","bitstream vera sans mono",monospace;font-size:0.95em"><span>'undef'</span></code>.)</div><div class="gmail_extra"><br></div><div class="gmail_extra">"Before" is not a well-defined term :)  (the end code says after, which has similar problems) </div><div class="gmail_extra"><br></div><div class="gmail_extra">Trivial case: </div><div class="gmail_extra"><br></div><div class="gmail_extra">Two block loop consists, lifetime maker at beginning</div><div class="gmail_extra"><br></div><div class="gmail_extra">A </div><div class="gmail_extra">|  ^</div><div class="gmail_extra">|    \  </div><div class="gmail_extra">|    |</div><div class="gmail_extra">|   |</div><div class="gmail_extra">v /</div><div class="gmail_extra">B</div><div class="gmail_extra"><br></div><div class="gmail_extra">Lifetime marker is at top of A.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Is B before A? (if not, are we using dominates as the definition of "before", because B is a predecessor of A)</div><div class="gmail_extra">Does the answer change if i put a jump to B somewhere above A?</div><div class="gmail_extra">If we use dominates, and i put a jump there, i can make A and B dominator tree siblings.  Is the pointer now invalid? :)</div><div class="gmail_extra"><br></div><div class="gmail_extra">etc</div><div class="gmail_extra"><br></div><div class="gmail_extra">I suspect what is really wanted is "i want lifetime markers to specify that this thing has single-iteration scope, function scope, or SESE/SEME region scope"  (or something).</div></div></blockquote><div><br></div><div><br></div><div>Also having lifetime.start marker seems unnecessary and it makes live range analysis less precise actually.  One local var can have one single end marker and multiple implicit start markers (first uses). The end marker should post-dominate all uses. Having one start marker is like defining a least common dominator for all the implicit starts which make the resulting live range strictly 'larger' than necessary.</div><div><br></div><div>David</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5"><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 1, 2016 at 8:36 AM, David Blaikie via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</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 dir="ltr">Would we want to wrap any of the allocas we do import while inlining in extra lifetime markers? (not sure if nested lifetime markers are supported/meaningful - maybe just in the case where there are no lifetime markers already?) So that non-Clang IR clients still get stack reuse for inlined stack slots? </div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><div><div><div dir="ltr">On Sun, Jul 31, 2016 at 9:48 PM Chandler Carruth via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div dir="ltr">Chris added alloca merging in the inliner a looooong time ago, 2009. The reason he added it was because at the time we didn't do stack coloring and without it we had serious stack size problems in LLVM.<div><br></div><div>Since then, a few rather important things have changed:</div><div>- We have reasonably powerful stack coloring support in the backend based on lifetime markers</div><div>- Clang<span style="line-height:1.5"> </span><span style="line-height:1.5">(the primary frontend I'm aware of that hit issues with this)</span><span style="line-height:1.5"> is now emitting lifetime markers for essentially everything</span></div><div>- Clang even has front-end based -O0 stack reuse tricks</div><div>- AliasAnalysis has become even more important (extended to codegen time etc) and relies heavily on distinguishing between allocas.</div><div>- We have lots of tools like the sanitizers that directly reason about allocas to catch bugs in user programs.</div><div><br></div><div>The first two changes pretty much completely obviate the need for alloca merging as far as I'm aware, and the second two changes make the information loss caused by this practice, IMO, really bad.</div><div><br></div><div>Even if there are problems exposed by turning off alloca merging in the inliner, they are almost certainly deficiencies in stack coloring, Clang, or other parts of the optimizer that we should fix rather than continue to ignore.</div><div><br></div><div>Thoughts? The code changes are easy and mechanical. My plan would be:</div><div>1) Add a flag to turn this off.</div><div>2) Run benchmarks with flag to make sure things are actually working.</div><div>3) Change default for the flag, make sure chaos doesn't ensue.</div><div>4) Delete the (quite substantial) complexity associated with this and the flag.</div><div>5) Profit!</div><div><br></div><div>-Chandler</div></div></div></div><span>
_______________________________________________<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>
</span></blockquote></div></div>
<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>
<br></blockquote></div><br></div></div></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">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>
<br></blockquote></div><br></div></div>