search for: reassociate

...tive 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: https://godbolt.org/g/64NmJM https://rise4fun.com/Alive/wec Currently, responsibility for reassociative transforms is split between -reassociate and -instcombine. I don't know if that split is intentional...

( ​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.llvm.org/D46336#1087082>). I assumed this isn't not what we want to do ​? My impression is we don't d...

...6336 <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" multiple times to > ​fold > down to what we want (relating to my comment here > <https://reviews.llvm.org/D46336#1087082>). I assum...

...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 >> ​​: >> >> >> 1. Since -reassociate isn't a fixed point pass, >> > > This is fixable, fwiw, without fixpointing it. > How? > >> we might need to repeat "-instcombine -reassociate" multiple times to >> ​fold >> down to what we want (relating to my comment here >> <https://...

...>>>>> ​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? >>> >> >> Depends on specifically which part you would like to know about ;) >> > > ​M...

....) >>> >>> 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? > Depends on specifically which part you would like to know about ;) > > >> >>> we might need to repeat "-instcombine -reassociate&quot...

...> ​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? >> > > Depends on specifically which part you would like to know about ;) > ​Maybe I misunderstood what you meant by "This...

...tion, >>>>>> 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? >>>> >>> >>> Depends on specifically which part you would like to...

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

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

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

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

...t; 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? >>>>> >>>> >>>> Depends on speci...

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

...t; 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? > > > Depends on specifically which part you would like to > know...

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

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

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 > > ; RUN:...

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

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