search for: reassociative

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

.... I assumed this isn't not what we want to do ​? My impression is we don't do a fixed-point with passes? 2. ​Since -reassociate needs to come up with one operand order (at least currently as the only reassociate pass), would there exist a single, unique operand order that would enable all reassociative/commutative foldings that we want? If not, could there be conflicts among different reassociation orders depending on what folding we want? On Tue, May 8, 2018 at 9:19 AM Sanjay Patel <spatel at rotateright.com> wrote: > There are at least 3 active proposals to add reassociative optimi...

...ractical difference between passes that we fixpoint externally and fixpoint internally. > > 2. > ​Since -reassociate needs to come up with one operand order (at least > currently as the only reassociate pass), would there exist a single, > unique operand order that would enable all reassociative/commutative > foldings that we want? > In what way? Are you asking whether there is a single reassociation order that makes all foldings occur in the same operation or something? I don't feel like i understand what you are asking. > If not, could there be conflicts among different r...

...ical difference, I don't see any problem with that :) > >> >> > 2. >> ​Since -reassociate needs to come up with one operand order (at least >> currently as the only reassociate pass), would there exist a single, >> unique operand order that would enable all reassociative/commutative >> foldings that we want? >> > > In what way? > Are you asking whether there is a single reassociation order that makes > all foldings occur in the same operation or something? > I don't feel like i understand what you are asking. > Does this rephrase...

...;>>> >>>>> >>>> 2. >>>>> ​Since -reassociate needs to come up with one operand order (at least >>>>> currently as the only reassociate pass), would there exist a single, >>>>> unique operand order that would enable all reassociative/commutative >>>>> foldings that we want? >>>>> >>>> >>>> In what way? >>>> Are you asking whether there is a single reassociation order that makes >>>> all foldings occur in the same operation or something? >>>&g...

...lem with > that :) > > >> >>> >>> >> 2. >>> ​Since -reassociate needs to come up with one operand order (at least >>> currently as the only reassociate pass), would there exist a single, >>> unique operand order that would enable all reassociative/commutative >>> foldings that we want? >>> >> >> In what way? >> Are you asking whether there is a single reassociation order that makes >> all foldings occur in the same operation or something? >> I don't feel like i understand what you are askin...

...gt; >>> >>>> >>>> >>> 2. >>>> ​Since -reassociate needs to come up with one operand order (at least >>>> currently as the only reassociate pass), would there exist a single, >>>> unique operand order that would enable all reassociative/commutative >>>> foldings that we want? >>>> >>> >>> In what way? >>> Are you asking whether there is a single reassociation order that makes >>> all foldings occur in the same operation or something? >>> I don't feel like i u...

...t;>>> 2. >>>>>> ​Since -reassociate needs to come up with one operand order (at >>>>>> least currently as the only reassociate pass), would there exist a >>>>>> single, unique operand order that would enable all >>>>>> reassociative/commutative foldings that we want? >>>>>> >>>>> >>>>> In what way? >>>>> Are you asking whether there is a single reassociation order that >>>>> makes all foldings occur in the same operation or something? >>>&gt...

> 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

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

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

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

.... >>>>>>> ​Since -reassociate needs to come up with one operand order (at >>>>>>> least currently as the only reassociate pass), would there exist a >>>>>>> single, unique operand order that would enable all >>>>>>> reassociative/commutative foldings that we want? >>>>>>> >>>>>> >>>>>> In what way? >>>>>> Are you asking whether there is a single reassociation order that >>>>>> makes all foldings occur in the same operation or someth...

...t;>>>> ​Since -reassociate needs to come up with one operand order (at >>>>>>>> least currently as the only reassociate pass), would there exist a >>>>>>>> single, unique operand order that would enable all >>>>>>>> reassociative/commutative foldings that we want? >>>>>>>> >>>>>>> >>>>>>> In what way? >>>>>>> Are you asking whether there is a single reassociation order that >>>>>>> makes all foldings occur in the same...

...ciate needs to come up with > one operand order (at least currently as > the only reassociate pass), would there > exist a single, unique operand order that > would enable all reassociative/commutative > foldings that we want? > > > In what way? > Are you asking whether there is a single > reassociation order that makes all foldings > occur i...

...t;> ​Since -reassociate needs to come up with one operand order (at >>>>>>>>> least currently as the only reassociate pass), would there exist >>>>>>>>> a single, unique operand order that would enable all >>>>>>>>> reassociative/commutative foldings that we want? >>>>>>>>> >>>>>>>> >>>>>>>> In what way? >>>>>>>> Are you asking whether there is a single reassociation order that >>>>>>>> makes all foldin...

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