<div class="gmail_extra"><div class="gmail_quote">On Sat, Apr 21, 2012 at 8:39 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
After reading the implementation of Reassociate much more carefully, I've convinced myself it belongs there. =] There is already quite a bit of logic in reassociate to minimize the operations required to compute a result when that computation happens to be reassociative. There was even a commented out case for optimizing multiplications accordingly. I've refactored this logic to fit into that model, which required substantial changes. I've also fixed it such that it actually reaches the fixed point immediately. We run reassociate on each layer of the minimized computation, and in fact can run it on the final computation, and nothing else changes. That seems to make it a nice canonical representation. Also, I've tweaked it to avoid modifying the computation as much as possible.<div>
<br></div><div>I think this is reasonable to commit in its current form, but as Richard has pointed out on IRC, it doesn't quite find all opportunities for minimizing the number of multiplications. I'm looking into an algorithmic tweak to catch the remaining cases, but I don't expect that would change the fundamental formulation of the optimization.</div>
</blockquote><div><br></div><div>Ok, I've done my homework now, and I think this is probably as far as I'm interested in taking this.</div><div><br></div><div>We could use one of the fancy algorithms for generating near-minimal arithmetic chain multi-exponentiation multiplication sequences (such as Pippenger's) but I'm not convinced its worth the substantial complexity. Just the basic binary exponentiation technique this patch uses is likely to be sufficient for most (small) products we're likely to see in real programs.</div>
<div><br></div><div>At most, it might be interesting to get CSE to look through chains of reassociative operations more aggressively -- it doesn't always seem possible for the reassociate pass to align things just right for it...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>-Chandler</div><div><br><div class="gmail_quote"><div><div class="h5">On Fri, Apr 20, 2012 at 2:23 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">Hello,<div><br></div><div>Richard and I hacked up a simple patch to form minimal multiply DAGs when intermediate results are unused. The code should handle fully generic formation of a minimal DAG of multiplies, sharing intermediate values where-ever possible. Check out the test cases for some of the fun simplifications it performs.</div>
<div><br></div><div>The only real problem is where to put it. Currently I've put it in InstCombine, but not because that's really a good home for it (in fact, it can't be the home, read on). The most "natural" home for this type of transform is the Reassociate pass, but that has its own problems....</div>
<div><br></div><div>The reassociate pass does a really nice job of canonicalizing chains of operations into left-linear trees that fully expose each intermediate operation for CSE and combining with other operations. This is a really nice property that seems a shame to loose. If we form the minimal multiply DAG in reassociate eagerly, we may miss chances to combine non-minimal intermediate steps with other operations.</div>
<div><br></div><div>However, if we use a cleanup pass like instcombine to mop up one-use left-linear trees like this patch does, we can easily get Reassociate and InstCombine dueling over the canonical form, and into an inf-loop we go.</div>
<div><br></div><div>One possible fix is to have InstCombine form a left-linear tree after it forms the minimal folding to try to keep Reassociate from undoing its work... but this all feels a bit hackish. Especially the deferred-processing hack required to ensure InstCombine performs this optimization on the entire tree at once. Suggestions?</div>
<br></div></div>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>