[PATCH] D32563: Improve code placement algorithm in Reassociate pass.

[Dehao Chen via llvm-commits]

Sorry that I may not have clarified the goal of the patch clearly.
It's not simply code placement (which is the job of general live-range
shrinking), but code placement + reassociation.

This patch optimizes expressions like (a+b+c+d). It chooses the order
to make the computation close to its definition to minimize
life-range.

E.g. original code:

d = foo();
c = foo();
b = foo();
a = foo();
t = a + b
t = t + c
t = t + d

is translated to:

d = foo();
c = foo();
t = d + c;
b = foo();
t = t + b;
a = foo();
t = t + a;

Of cause we can make this transformation 2 phases:
1. live-range aware reassociation
2. general live-range shrinking

But when we are at #1, we do need to know the dominance relation of
all operands, thus it will be free to do #2 (which also needs
dominance info) as well.

I'm not quite familiar with nary-reassociate, but looking from the
file-level comment, it seem to address the issue of removing redundant
computation. For the case in this patch, there is no redundant
computation, thus may not apply to nary-reassociation case?

Thanks,
Dehao

On Thu, Apr 27, 2017 at 3:44 PM, Daniel Berlin via Phabricator
<reviews at reviews.llvm.org> wrote:
> dberlin added a comment.
>
> The whole point of starting to rewrite-reassociate as n-ary reassociate was to have a better framework to handle better reassociation and placement issues.
> Reassociate is supposed to be a simple, and dumb, reassociate.
>
> Trying to integrate code placement into it seems like a ... bad plan.
> It's neither structured in a way that you can easily make such a thing fast, nor can you really do a good job of it.
>
>
> https://reviews.llvm.org/D32563
>
>
>