[llvm-commits] PATCH: Teach LLVM to form minimal multiply DAGs

[Chandler Carruth]

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.

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.

-Chandler

On Fri, Apr 20, 2012 at 2:23 AM, Chandler Carruth <chandlerc at gmail.com>wrote:

> Hello,
>
> 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.
>
> 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....
>
> 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.
>
> 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.
>
> 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?
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120421/f14146f9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: min-multiplies.diff
Type: application/octet-stream
Size: 13672 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120421/f14146f9/attachment.obj>