<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 11/05/2014 10:10 AM, Reid Kleckner
      wrote:<br>
    </div>
    <blockquote
cite="mid:CACs=tyKpi53=7J-khTE+4w+tbyDcr_mfREVM-8kZmTyo5FW3Vg@mail.gmail.com"
      type="cite">
      <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 moz-do-not-send="true"
                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>
    </blockquote>
    Everything you say here is general goodness.  What part of this is
    problematic today?  My belief is that the lifetime markers give you
    exactly the support you need.  Where does this break down?  Is the
    analysis too hard?  Is Clang getting the semantics wrong?  What's
    the actually blocking issue?<br>
    <br>
    Philip<br>
    <br>
  </body>
</html>