[PATCH] [SLSR] simplify ternary adds by reassociation

[Jingyue Wu]

Hi Sanjoy,

I agree the reassociation performed here is generally good, and I wish I
could put it in -reassociate.

However, I have two major concerns.
1. The algorithm in -reassociate is local in the sense that it ranks nodes
in each individual expression tree and reorders them according to their
ranks. The algorithm implemented here is global: it reassociates an
expression in the way that we can leverage other instructions in the same
function. I also found the workflow of my algorithm nicely fit into SLSR
which scans instructions in the DFS order and simplifies them with respect
to their dominators.
2. -reassociate happens too early. Many opportunities I discovered are
exposed after loop unrolling, but -reassociate happens before loop
unrolling.

Jingyue

On Wed, Apr 8, 2015 at 1:23 PM Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:

> Should this rule live inside `-reassociate`?  Optimizing
>
>    define void @reassociate(i32 %a, i32 %b, i32 %c) {
>     %1 = add i32 %a, %c
>     call void @foo(i32 %1)
>     %2 = add i32 %a, %b
>     %3 = add i32 %2, %c
>     call void @foo(i32 %3)
>     ret void
>   }
>
> to
>
>    define void @reassociate(i32 %a, i32 %b, i32 %c) {
>     %1 = add i32 %a, %c
>     call void @foo(i32 %1)
>     %3 = add i32 %1, %b
>     call void @foo(i32 %3)
>     ret void
>   }
>
> looks like a generally good idea to me.
>
>
> http://reviews.llvm.org/D8898
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150408/30431b72/attachment.html>