<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 5, 2014 at 10:01 AM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><blockquote type="cite"><div>
      </div>
    </blockquote></span>
    Would one of you mind taking a step back and explaining what you
    believe the "stack colouring problem" to be?  I'm familiar with the
    general meaning of the term and even some of LLVM's implementation;
    I'm just not sure what specific issue you're referring to.   Having
    the context would make it much easier to assess your proposals.  </div></blockquote><div><br></div><div>The goal of stack coloring is to reduce stack usage by storing user data with non-overlapping lifetimes in the same stack memory.</div><div><br></div><div>C/C++ source programs usually have a naturally scoped structure, where the lifetime of data is bounded by curly braces. This information reduces the lifetime that stack coloring sees, so it saves stack memory.</div><div><br></div><div>When we go to LLVM IR, we lose all that information. We currently try to recapture it with calls to @lifetime.start / end intrinsic calls at the point of declaration and when the variable falls out of scope. Basically we're trying to figure out how to put that scoping information back into the IR without turning it back into a tree.</div><div><br></div><div>Furthermore, if we had better information about this in the IR, we could augment ASan to detect use-after-scope.</div></div></div></div>