<div dir="ltr">Yeah, this is a reverse variant of the example i posted to david blaikie :)<div><br></div><div>Assuming y'all are certain this is supposed to do something sensible in C, outside of "stop emitting lifetime markers in functions with jumps past variable initialization", getting a conservatively right answer is ... non-trivial AFAIK.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 1, 2016 at 5:51 PM, Duncan P. N. Exon Smith 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">I just want to note that there's currently a miscompile in C code with lifetime markers:<br>
  <a href="http://lists.llvm.org/pipermail/cfe-dev/2016-July/050066.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/cfe-dev/2016-July/050066.html</a><br>
<br>
Depending on how we fix that, we could end up being more pessimistic about when markers are emitted.  I suggest we fix that before benchmarking this change.<br>
<div class="HOEnZb"><div class="h5"><br>
> On 2016-Jul-31, at 21:47, Chandler Carruth via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> 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.<br>
><br>
> Since then, a few rather important things have changed:<br>
> - We have reasonably powerful stack coloring support in the backend based on lifetime markers<br>
> - Clang (the primary frontend I'm aware of that hit issues with this) is now emitting lifetime markers for essentially everything<br>
> - Clang even has front-end based -O0 stack reuse tricks<br>
> - AliasAnalysis has become even more important (extended to codegen time etc) and relies heavily on distinguishing between allocas.<br>
> - We have lots of tools like the sanitizers that directly reason about allocas to catch bugs in user programs.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Thoughts? The code changes are easy and mechanical. My plan would be:<br>
> 1) Add a flag to turn this off.<br>
> 2) Run benchmarks with flag to make sure things are actually working.<br>
> 3) Change default for the flag, make sure chaos doesn't ensue.<br>
> 4) Delete the (quite substantial) complexity associated with this and the flag.<br>
> 5) Profit!<br>
><br>
> -Chandler<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<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>
_______________________________________________<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>
</div></div></blockquote></div><br></div>