<html>
    <head>
      <base href="http://llvm.org/bugs/" />
    </head>
    <body><span class="vcard"><a class="email" href="mailto:chandlerc@gmail.com" title="Chandler Carruth <chandlerc@gmail.com>"> <span class="fn">Chandler Carruth</span></a>
</span> changed
              <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED FIXED - LoopDeletion: lib/IR/Value.cpp:79: virtual llvm::Value::~Value(): Assertion `use_empty() && "Uses remain when a value is destroyed!"' failed."
   href="http://llvm.org/bugs/show_bug.cgi?id=18616">bug 18616</a>
        <br>
             <table border="1" cellspacing="0" cellpadding="8">
          <tr>
            <th>What</th>
            <th>Removed</th>
            <th>Added</th>
          </tr>

         <tr>
           <td style="text-align:right;">Status</td>
           <td>NEW
           </td>
           <td>RESOLVED
           </td>
         </tr>

         <tr>
           <td style="text-align:right;">Resolution</td>
           <td>---
           </td>
           <td>FIXED
           </td>
         </tr></table>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED FIXED - LoopDeletion: lib/IR/Value.cpp:79: virtual llvm::Value::~Value(): Assertion `use_empty() && "Uses remain when a value is destroyed!"' failed."
   href="http://llvm.org/bugs/show_bug.cgi?id=18616#c4">Comment # 4</a>
              on <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED FIXED - LoopDeletion: lib/IR/Value.cpp:79: virtual llvm::Value::~Value(): Assertion `use_empty() && "Uses remain when a value is destroyed!"' failed."
   href="http://llvm.org/bugs/show_bug.cgi?id=18616">bug 18616</a>
              from <span class="vcard"><a class="email" href="mailto:chandlerc@gmail.com" title="Chandler Carruth <chandlerc@gmail.com>"> <span class="fn">Chandler Carruth</span></a>
</span></b>
        <pre>This was fixed with r200273.

I spent a lot of time looking at this even after applying that fix worried that
there was a deeper issue here. The interesting question is -- if we have to
recursively reform LCSSA even across sibling loops to the unrolled loop, why is
*this* amount of LCSSA-formation sufficient? Why don't we need to handle the
case of sibling top-level loops?

The answer (at last) is that the thing which is destroying LCSSA is not the
loop unroller. It is actually reasonable careful to preserve LCSSA, and at
least in the test cases I have it does so. But it *doesn't* preserve loop
simplify, and loop simplify is what destroys LCSSA. Notably, the loop simplify
form which is most directly impacted by unrolling is that of any outer loop
into which we unroll because we may need to reform the loop nest structure
itself. But once we do that, LCSSA is gone. Because loop simplify is a
recursive loop nest transformation, so must our reapplication of LCSSA be. The
thing which was touching a sibling of the unrolled loop was the loop simplify
bit itself, and so exactly that much must have LCSSA recomputed for it.


This is still crazy wasteful. We should either teach LoopSimplify to detect,
use, form, and preserve LCSSA or we should move away from LCSSA. It would also
be nice to teach loop unroll to preserve loop simplified form in all cases, but
that's an entire other can of worms.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>