search for: reassoci

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

( ​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://review...

...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&q...

...; 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? > &...

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

...> >>> ( >>> ​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,...

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

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

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

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

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

...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 >>>>>>> ​​: >>>>>>> >>>>>>> >&g...

...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 >>>>>>>> ​​: >>>>>>>> >>&gt...

...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 > ​​: > > >...

...think a header has moved, so it doesn't build as-is. I'd like to know if it can catch the cases in D45842. If not, why not? If it can handle those easily, I'll abandon D45842. Also, I don't know if it's better to include that functionality 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 t...

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 = pairings that already exist in the source IR Given that, we should probably group everything in favor of existing pairings when...

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. > > Let's take nary-add.ll, left_reassociate > > ; RU...

>> 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"); >> assert(NumAddedValues > 1 && "Each occurren...

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 the fix you suggested. These case...