search for: reassociation

There are at least 3 active proposals to add reassociative optimizations in IR: [1] D41574 <https://reviews.llvm.org/D41574>- a new pass for reassociation/factoring [2] D46336 <https://reviews.llvm.org/D46336> - enhance -instcombine to do more reassociation/factoring [3] D45842 <https://reviews.llvm.org/D45842> - add to the existing -reassociate pass to enable factoring Here's a basic motivating example that we fail to optimize: http...

( ​I came across this issue in the context of D46336 <https://reviews.llvm.org/D46336>. ​ ​ Thanks, Sanjay, for starting this discussion.) If ​we will move ​reassociation, or keep additional ones ​,​ out of instcombine, ​open questions for me would be ​​: 1. Since -reassociate isn't a fixed point pass, we might need to repeat "-instcombine -reassociate" multiple times to ​fold down to what we want (relating to my comment here <https://reviews.llv...

...10:38 AM, Hiroshi Yamauchi via llvm-dev < llvm-dev at lists.llvm.org> wrote: > ( > ​I came across this issue in the context of > D46336 <https://reviews.llvm.org/D46336>. > ​ ​ > Thanks, Sanjay, for starting this discussion.) > > If > ​we will > move > ​reassociation, > or keep additional ones > ​,​ > out of instcombine, > ​open questions for me would be > ​​: > > > 1. Since -reassociate isn't a fixed point pass, > This is fixable, fwiw, without fixpointing it. > we might need to repeat "-instcombine -reassociate"...

...; llvm-dev at lists.llvm.org> wrote: > >> ( >> ​I came across this issue in the context of >> D46336 <https://reviews.llvm.org/D46336>. >> ​ ​ >> Thanks, Sanjay, for starting this discussion.) >> >> If >> ​we will >> move >> ​reassociation, >> or keep additional ones >> ​,​ >> out of instcombine, >> ​open questions for me would be >> ​​: >> >> >> 1. Since -reassociate isn't a fixed point pass, >> > > This is fixable, fwiw, without fixpointing it. > How? > >&g...

...e context of >>>>> D46336 <https://reviews.llvm.org/D46336>. >>>>> ​ ​ >>>>> Thanks, Sanjay, for starting this discussion.) >>>>> >>>>> If >>>>> ​we will >>>>> move >>>>> ​reassociation, >>>>> or keep additional ones >>>>> ​,​ >>>>> out of instcombine, >>>>> ​open questions for me would be >>>>> ​​: >>>>> >>>>> >>>>> 1. Since -reassociate isn't a fixed point...

...> >>> ( >>> ​I came across this issue in the context of >>> D46336 <https://reviews.llvm.org/D46336>. >>> ​ ​ >>> Thanks, Sanjay, for starting this discussion.) >>> >>> If >>> ​we will >>> move >>> ​reassociation, >>> or keep additional ones >>> ​,​ >>> out of instcombine, >>> ​open questions for me would be >>> ​​: >>> >>> >>> 1. Since -reassociate isn't a fixed point pass, >>> >> >> This is fixable, fwiw, with...

...​I came across this issue in the context of >>>> D46336 <https://reviews.llvm.org/D46336>. >>>> ​ ​ >>>> Thanks, Sanjay, for starting this discussion.) >>>> >>>> If >>>> ​we will >>>> move >>>> ​reassociation, >>>> or keep additional ones >>>> ​,​ >>>> out of instcombine, >>>> ​open questions for me would be >>>> ​​: >>>> >>>> >>>> 1. Since -reassociate isn't a fixed point pass, >>>> >>&...

...;> D46336 <https://reviews.llvm.org/D46336>. >>>>>> ​ ​ >>>>>> Thanks, Sanjay, for starting this discussion.) >>>>>> >>>>>> If >>>>>> ​we will >>>>>> move >>>>>> ​reassociation, >>>>>> or keep additional ones >>>>>> ​,​ >>>>>> out of instcombine, >>>>>> ​open questions for me would be >>>>>> ​​: >>>>>> >>>>>> >>>>>> 1. Since -reas...

...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 understan...

Hi, I encountered some bugs in Reassociate [1] where we are hitting some assertions: assert(!Duplicates.count(Factor) && "Shouldn't have two constant factors, missed a canonicalize"); assert(NumAddedValues > 1 && "Each occurrence should contribute a value”); My understanding is that these assertions enforce that when processing an

...ere: 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 rea...

1. The reassociate pass that exists right now was *originally* (AFAIK) written to enable CSE/GVN to do better. 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 oth...

...views.llvm.org/D46336>. >>>>>>> ​ ​ >>>>>>> Thanks, Sanjay, for starting this discussion.) >>>>>>> >>>>>>> If >>>>>>> ​we will >>>>>>> move >>>>>>> ​reassociation, >>>>>>> or keep additional ones >>>>>>> ​,​ >>>>>>> out of instcombine, >>>>>>> ​open questions for me would be >>>>>>> ​​: >>>>>>> >>>>>>> >>&gt...

...gt;>>>>>>> ​ ​ >>>>>>>> Thanks, Sanjay, for starting this discussion.) >>>>>>>> >>>>>>>> If >>>>>>>> ​we will >>>>>>>> move >>>>>>>> ​reassociation, >>>>>>>> or keep additional ones >>>>>>>> ​,​ >>>>>>>> out of instcombine, >>>>>>>> ​open questions for me would be >>>>>>>> ​​: >>>>>>>> >>>>...

...views.llvm.org/D46336>. > ​ ​ > Thanks, Sanjay, for starting this discussion.) > > If > ​we will >  move > ​reassociation,  > or keep additional ones > ​,​ > out of instcombine, > ​open questions for me would be > ​​: > > > 1. Si...

...nctionality as another iteration of the existing -reassociate or split it off as its own pass. But I think it should do the distributive simplifications that are currently in -instcombine (InstCombiner::SimplifyUsingDistributiveLaws). Using that instsimplify logic for analysis lets us decide if the reassociation is worthwhile in the 1st place, it removes the risk that some other pass would somehow mess up the pattern before instcombine could zap it, and it reduces the burden on instcombine to be the entire optimizer. :) On Mon, May 14, 2018 at 1:34 PM, Hiroshi Yamauchi via llvm-dev < llvm-dev at lists...

On Tue, May 5, 2015 at 10:20 AM, Jingyue Wu <jingyue at google.com> wrote: > Hi Daniel, > > I presume you mean, instead of assigning function arguments distinct ranks > (http://llvm.org/docs/doxygen/html/Reassociate_8cpp_source.html#l00282), we > should group function arguments in favor of existing pairings. Existing = pairings reassociate already chose before *not* existing

Whoops, forgot llvmdev On Mon, May 4, 2015 at 4:12 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > So i started by looking at naryreassociate, whose pass > description/reason listed for doing it is actually describes bug in > reassociate, and discovered that, in fact, reassociate seems broken, > and should be doing the right thing on most of your testcases. > >

>> On Feb 2, 2015, at 11:12 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >> Hi, >> >> I encountered some bugs in Reassociate [1] where we are hitting some >> assertions: >> >> assert(!Duplicates.count(Factor) && >> "Shouldn't have two constant factors, missed a >> canonicalize");

Hi Daniel, I presume you mean, instead of assigning function arguments distinct ranks ( http://llvm.org/docs/doxygen/html/Reassociate_8cpp_source.html#l00282), we should group function arguments in favor of existing pairings. You are not suggesting discarding the entire ranking system, right? I'll look into how that works on my benchmarks. AFAIK, we encountered some cases that seem beyond