[llvm-dev] more reassociation in IR

[Sanjay Patel via llvm-dev]

When you say that distribution shouldn't be used, do you mean within
instcombine rather than some other pass? Or not all as an IR optimization?

A dedicated optimization pass that looks for and makes
factoring/distribution folds to eliminate instructions seems like it would
solve the problems that I'm seeing.
Ie, I'm leaning towards the proposal here: https://reviews.llvm.org/D41574
But I'd make it less "weak". :)

Ideally, that allows removing duplicate functionality from instcombine, but
I'm guessing that it will take a lot of work to cut that cord without
causing regressions. Note that instcombine even has a specialized
reassociation pass-within-a-pass for fadd/fsub alone:
https://reviews.llvm.org/rL170471

On Tue, May 8, 2018 at 9:22 PM, Chris Lattner <clattner at nondot.org> wrote:

>
>
> On May 8, 2018, at 9:50 AM, Daniel Berlin via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> 1.  The reassociate pass that exists right now was *originally* (AFAIK)
> written to enable CSE/GVN to do better.
>
>
> Agreed.  The original mindset included a (naive) belief that going with a
> canonical form was better than teaching redundancy elimination to handle
> abstractions (as a matter of separation of concerns).  I think that that
> was a failed experiment at this point :-).  We should still canonicalize
> x*x*x into powi, but the more aggressive canonicalization (like
> distribution) shouldn’t be used IMO.
>
> -Chris
>
>
>
> That particular issue is solvable in other ways, because there are good
> ways to integrate reassociation into CSE/GVN (and at this point, it would
> probably be cheaper than -reassociate since it would modify code less, only
> changing it when there are actual redundancies )
>
> I don't know what other things people are trying to target with
> reassociate these days, it would be good to understand what others see as
> the use cases.
>
> My only other fear with removing it is that we have a tendency to try to
> make every optimization do everything, so i fear removing reassociate might
> just have people try to improve every pass to do reassociation instead of
> declaring what is good enough.
>
> (For example, GVN already does some reassociation, as do some analysis.
> Other analysis relies more on a canonical form existing and don't, for
> example, try to perform commutativity on their own.  IMHO, we should just
> declare one or the other to be the case, and hold that line, rather than
> generate a mishmash)
>
>
> 2. "Keep in mind that instcombine runs 1st, runs to fixed-point, and runs
> 8 times in the -O2 pipeline."
>
> Y'all know how i feel about this one, so i'll leave it alone :)
>
>
>
> --Dan
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180509/1a60bbf7/attachment.html>