<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>Hi Vedant,</p>
    <p>Thanks a lot for your comments!</p>
    <p>>It looks like a lot of the new infrastructure introduced <a href="https://github.com/djolertrk/llvm-di-checker/commit/9d26ac2557c584f6cf82ac5535fc47f8bd267a27" class="">here</a> consists of logic copied from the debugify
      implementation. Why is introducing a new pair of passes better
      than extending the ones we have? The core infrastructure needed to
      track location loss for real (non-synthetic) source variables is
      is in place already.</p>
    <p>Since it is a proposal, I thought it'd easier to understand the
      idea if I duplicate things. Ideally, we can make an API that could
      be used from both tools. Initially, I made a few patches locally
      turning the real debug info into debugify ones, but I realized it
      breaks the original idea/design of the debugify & that is why
      I decided to make a separate pass(es). This cannot stay as is with
      the respect to the implementation, it should be either merged into
      debugify file(s) or refactored using the API mentioned above.
      Another reason for implementing it as a different pass was the
      fact the debugify is meant to be used from 'opt' level only, but
      if we want to invoke the option from front end level, we need to
      merge it into the IR library.<br>
    </p>
    <div class=""><br>
    </div>
    <div class="">>Stepping back a bit, I’m also surprised by the
      decision to move away from synthetic testing when there’s still so
      much low-hanging fruit to pick using that technique. The example
      from <a href="https://reviews.llvm.org/D81939" class="">https://reviews.llvm.org/D81939</a> illustrates
      this perfectly: in this case it’s not necessary to invent a new
      testing technique to uncover the bug, because simply running
      `./bin/llvm-lit -Dopt="opt -debugify-each"
      test/Transforms/DeadArgElim` finds the same issue.</div>
    <p>As I mentioned in the previous mail, I do really think the
      debugify technique is great & I use it. But, in order to
      detect that variable "x" was optimized-out starting from pass Y, I
      only run the di-checker option (that performs analysis only) &
      find the variable in the final html report. I think that is very
      user friendly concept. At the end, when we detected what was the
      spot of loosing the location, we can run debugify on the
      pass-directory-tests (but there is a concern the tests does not
      cover all the possible cases; and the case found from the high
      level could be new to the pass). In addition, the di-checker
      detects issues for metadata other than locations (currently, the
      preservation map keeps the disubprograms only, but it should keep
      other kinds too).<br>
    </p>
    <p><br>
    </p>
    <p>>In D81939, you discuss finding the new tool useful when
      responding to bug reports about optimized-out variables or missing
      locations. We sorely do need something better than
      -opt-bisect-limit, but why not start with something simple?
      -check-debugify already knows how to report when & where a
      location is dropped, it would be simple to teach it to emit a
      report when a variable is fully optimized-out.</p>
    <p>I agree. We can do that and that could be used from both
      utilities.<br>
    </p>
    <p><br>
    </p>
    <p>Best regards,</p>
    <p>Djordje</p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 17.6.20. 21:14, Vedant Kumar wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:74E217F2-67F5-44FF-BAA1-470DEFB75549@apple.com">
      
      Hey Djordje,
      <div class=""><br class="">
      </div>
      <div class="">It looks like a lot of the new infrastructure
        introduced <a href="https://github.com/djolertrk/llvm-di-checker/commit/9d26ac2557c584f6cf82ac5535fc47f8bd267a27" class="" moz-do-not-send="true">here</a> consists of logic
        copied from the debugify implementation. Why is introducing a
        new pair of passes better than extending the ones we have? The
        core infrastructure needed to track location loss for real
        (non-synthetic) source variables is is in place already.</div>
      <div class=""><br class="">
      </div>
      <div class="">Stepping back a bit, I’m also surprised by the
        decision to move away from synthetic testing when there’s still
        so much low-hanging fruit to pick using that technique. The
        example from <a href="https://reviews.llvm.org/D81939" class="" moz-do-not-send="true">https://reviews.llvm.org/D81939</a> illustrates
        this perfectly: in this case it’s not necessary to invent a new
        testing technique to uncover the bug, because simply running
        `./bin/llvm-lit -Dopt="opt -debugify-each"
        test/Transforms/DeadArgElim` finds the same issue.</div>
      <div class=""><br class="">
      </div>
      <div class="">In D81939, you discuss finding the new tool useful
        when responding to bug reports about optimized-out variables or
        missing locations. We sorely do need something better than
        -opt-bisect-limit, but why not start with something simple?
        -check-debugify already knows how to report when & where a
        location is dropped, it would be simple to teach it to emit a
        report when a variable is fully optimized-out.</div>
      <div class=""><br class="">
      </div>
      <div class="">
        <div><br class="">
          <blockquote type="cite" class="">
            <div class="">On Jun 17, 2020, at 2:10 AM, Djordje <<a href="mailto:djordje.todorovic@syrmia.com" class="" moz-do-not-send="true">djordje.todorovic@syrmia.com</a>>
              wrote:</div>
            <div class="">
              <div class=""><br class="">
                I am sharing the proposal [0] which gives a brief
                introduction for the implementation of the LLVM DI
                Checker utility. On a very high level, it is a pair of
                LLVM (IR) Passes that check the preservation of the
                original debug info in the optimizations. There are
                options controlling the passes, that could be invoked
                from ``clang`` as well as from ``opt`` level.<br class="">
                <br class="">
                By testing the utility on the GDB 7.11 project (using it
                as a testbed), it has found a certain number of
                potential issues regarding the DILocations (using it on
                LLVM project build itself, it has found one bug
                regarding DISubprogram metadata). Please take a look
                into the final report (on the GDB 7.11 testbed)
                generated from the script that collects the data at [1].
                By looking at these data, it looks that the utility like
                this could be useful when trying to detect the real
                issues related to debug info production by the compiler.<br class="">
              </div>
            </div>
          </blockquote>
          <div><br class="">
          </div>
          <div>Thanks for sharing these results. The data here is older
            (from the 2018 debug info BoF) and from a different project
            (sqlite3), but we saw some similar patterns: <a href="https://llvm.org/devmtg/2018-10/slides/Prantl-Kumar-debug-info-bof-2018.pdf" class="" moz-do-not-send="true">https://llvm.org/devmtg/2018-10/slides/Prantl-Kumar-debug-info-bof-2018.pdf</a></div>
          <div><br class="">
          </div>
          <div>best</div>
          <div>vedant</div>
        </div>
      </div>
    </blockquote>
  </body>
</html>