<html>
    <head>
      <base href="https://bugs.llvm.org/">
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Consider backpropagating informations from uses to def"
   href="https://bugs.llvm.org/show_bug.cgi?id=33151">33151</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>Consider backpropagating informations from uses to def
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>libraries
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>trunk
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>PC
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>All
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>enhancement
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>Scalar Optimizations
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>unassignedbugs@nondot.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>davide@freebsd.org
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>dberlin@dberlin.org, filcab@gmail.com, llvm-bugs@lists.llvm.org, llvm-dev@redking.me.uk
          </td>
        </tr></table>
      <p>
        <div>
        <pre>Dan pointed me out to this a while ago, and given I discussed this with Simon
and Filipe recently, let me dump this somewhere :)
GCC implements some rudimental form of backpropagation from uses to defs.

This allows them to simplify this:

target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

define double @tinkywinky(double %x) {
  %patatino = tail call double @llvm.fabs.f64(double %x)
  %call = tail call double @llvm.cos.f64(double %patatino)
  ret double %call
}

declare double @llvm.fabs.f64(double)
declare double @llvm.cos.f64(double)


to just:

define double @tinkywinky(double %x) {
  %call = tail call double @llvm.cos.f64(double %x)
  ret double %call
}

as they can prove that the sign doesn't matter (i.e. cos(x) = cos(-x)).
Their optimistic algorithm used is just a simple series of walks (so it should
be quite fast), divided in 4 phases:

1) Walk of the function in PO, each BB backwards, collecting interesting
informations and initially ignoring PHIs.
2) Re-examine the PHIs and reprocess the uses until a maximal fixpoint is hit
3) RPO walk to propagate informations
4) PO walk to remove dead instructions

They currently just propagates sign bits, but I can see it being extended to
propagate more informations, e.g. known bits.

I'm not sure how often this triggers in practice, but in theory it should
improve the precision of constant propagation (as we would end up propagating
informations in both direction, backwards here and forward in SCCP).</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>