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

[Daniel Berlin via llvm-commits]

On Thu, Apr 27, 2017 at 1:42 PM, Wei Mi via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> On Thu, Apr 27, 2017 at 1:26 PM, Daniel Berlin via Phabricator
> <reviews at reviews.llvm.org> wrote:
> > dberlin added a comment.
> >
> > Isn't this close to what n-ary reassociate does?
> > (if so, why not just use that and disable this?)
> >
>
> Nary reassociate tries to maximize the redundency exposed by
> reassociation.


As does reassociate :)


> This patch tries to reduce the register pressure by
> changing where to insert the intermediate results of reassociation,
> and it doesn't try to improve the result of reassociation for better
> CSE/PRE/LICM optimizations.


I understand.


> The two have different motivations, so I
> don't see how nary reassociation can be helpful here.
>

The placement algorithm for computations that n-ary reassociate uses tries
to reuse existing computation points.
This patch tries to fix  "too many overlapped life-ranges. "

The algorithm it uses, to find nearest common dominator of operands, etc,
is pretty much what n-ary reassociate does:
"
  // Look for the closest dominator LHS of I that computes LHSExpr, and
replace
  // I with LHS op RHS.
"





> >
> > https://reviews.llvm.org/D32563
> >
> >
> >
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170427/b0565c27/attachment.html>