<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 01/23/2017 03:08 AM, Chandler
      Carruth wrote:<br>
    </div>
    <blockquote
cite="mid:CAAwGriEaH3opAyrfg6a43dFXJwdcrHfRnvCmDMHFM3shxjYMwA@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div dir="ltr">This thread kinda died. I'd like to revive it.
        <div><br>
        </div>
        <div>The new PM stuff is making excellent progress, and this is
          actually one of the last things to clean up.</div>
        <div><br>
          <div class="gmail_quote">
            <div dir="ltr">On Mon, Aug 8, 2016 at 1:10 AM Sean Silva
              <<a moz-do-not-send="true"
                href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>>
              wrote:<br>
            </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div dir="ltr" class="gmail_msg">
                <div class="gmail_extra gmail_msg">
                  <div class="gmail_quote gmail_msg">
                    <blockquote class="gmail_quote gmail_msg"
                      style="margin:0 0 0 .8ex;border-left:1px #ccc
                      solid;padding-left:1ex">
                      <div dir="ltr" class="gmail_msg">
                        <div class="gmail_msg">Thoughts? For the moment
                          I have put in a workaround (r274457) that
                          makes jump-threading invalidate LVI.</div>
                      </div>
                    </blockquote>
                    <div class="gmail_msg"><br class="gmail_msg">
                    </div>
                  </div>
                </div>
              </div>
              <div dir="ltr" class="gmail_msg">
                <div class="gmail_extra gmail_msg">
                  <div class="gmail_quote gmail_msg">
                    <div class="gmail_msg">Is everybody happy with this
                      workaround?</div>
                  </div>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>I wasn't too happy with it, but I had no better
              suggestion.</div>
            <div><br>
            </div>
            <div>As the infrastructure matured, what I think is a
              substantially less horrible workaround is available in the
              form of what I implemented in r292773. Instead of just
              working around this for each analysis, this works around
              it in GlobalDCE for *any* function analysis stashing an
              AssertingVH. The down side is that it only defends against
              *function* removal and *function* analyses. =[</div>
            <div><br>
            </div>
            <div>This may be a tiny bit better in some senses, but in
              others its worse, and frankly I think it is a pretty gross
              hack even in the best of cases. But let's take a look at
              some of the cases you identified:</div>
            <div><br>
            </div>
            <div>#1: CallGraph has an asserting VH on functions. But my
              workaround doesn't help at all, much to my surprise
              afterward! Why? Well of course because CallGraph is a
              *module analysis*. We can't just go invalidating every
              module analysis every time we remove a function... :: sigh
              ::</div>
            <div><br>
            </div>
            <div>#2: SCEV and LVI have *basic block* asserting VHs. For
              some reason, all the test cases I have stem from deleting
              an entire function, but there is no real reason that will
              be the case. It seems entirely plausible to nuke a basic
              block out from under one of these.</div>
            <div><br>
            </div>
            <div>So no, I think we need a better answer here.</div>
            <div><br>
            </div>
            <div><br>
            </div>
            <div>After thinking about this a lot, and trying and failing
              to implement less awful workarounds, I think AssertingVHes
              embedded in analysis results in fundamentally incompatible
              with caching of results.</div>
            <div><br>
            </div>
            <div>The cache gets invalidated automatically but not the
              instant the IR gets mutated. The assert happens too soon,
              and things blow up. I don't think we want to force cache
              invalidation logic in every pass that deletes a Value. =[</div>
            <div><br>
            </div>
            <div>So I think we should move away from AssertingVH in
              analysis results.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    I agree; having an analysis that all clients need to promise not to
    invalidate in certain ways is troublesome.<br>
    <br>
     -Hal<br>
    <br>
    <blockquote
cite="mid:CAAwGriEaH3opAyrfg6a43dFXJwdcrHfRnvCmDMHFM3shxjYMwA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div class="gmail_quote">
            <div> If you need a more powerful debugging tool than ASan
              (or analogous) provides, we can build a DebugOnlyWeakVH or
              some such that becomes null immediately in debug builds.
              Or that has a asserting-only-if-used behavior rather than
              the eager assert we have today. But I'm inclined to build
              that tool when folks are first debugging something and
              tools like ASan are insufficient rather than eagerly.111</div>
          </div>
        </div>
      </div>
    </blockquote>
    <blockquote
cite="mid:CAAwGriEaH3opAyrfg6a43dFXJwdcrHfRnvCmDMHFM3shxjYMwA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div class="gmail_quote">
            <div><br>
            </div>
            <div><br>
            </div>
            <div>Any objections to this? I'd really like to nuke the 3
              cases Sean identified in the tree (CallGraph, LVI, SCEV)
              and stop hacking around them.</div>
            <div><br>
            </div>
            <div>-Chandler</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
  </body>
</html>