search for: reassociated

.../Alive/wec Currently, responsibility for reassociative transforms is split between -reassociate and -instcombine. I don't know if that split is intentional or just how the code evolved. Debug stats for test-suite compiled with -O3 show: 78K "reassociations" by -instcombine. 58K "reassociated" by -reassociate A debug stat with D45842 showed that that transform fired 1.3K times. Keep in mind that instcombine runs 1st, runs to fixed-point, and runs 8 times in the -O2 pipeline. Reassociate runs 1 time and doesn't run to fixed-point. Some transforms are unique to 1 pass or the ot...

...sponsibility for reassociative transforms is split between > -reassociate and -instcombine. I don't know if that split is intentional or > just how the code evolved. Debug stats for test-suite compiled with -O3 > show: > 78K "reassociations" by -instcombine. > 58K "reassociated" by -reassociate > > A debug stat with D45842 showed that that transform fired 1.3K times. > > Keep in mind that instcombine runs 1st, runs to fixed-point, and runs 8 > times in the -O2 pipeline. Reassociate runs 1 time and doesn't run to > fixed-point. Some transforms ar...

...ssociative transforms is split between >> -reassociate and -instcombine. I don't know if that split is intentional or >> just how the code evolved. Debug stats for test-suite compiled with -O3 >> show: >> 78K "reassociations" by -instcombine. >> 58K "reassociated" by -reassociate >> >> A debug stat with D45842 showed that that transform fired 1.3K times. >> >> Keep in mind that instcombine runs 1st, runs to fixed-point, and runs 8 >> times in the -O2 pipeline. Reassociate runs 1 time and doesn't run to >> fixed-p...

...s is split between >>> -reassociate and -instcombine. I don't know if that split is intentional or >>> just how the code evolved. Debug stats for test-suite compiled with -O3 >>> show: >>> 78K "reassociations" by -instcombine. >>> 58K "reassociated" by -reassociate >>> >>> A debug stat with D45842 showed that that transform fired 1.3K times. >>> >>> Keep in mind that instcombine runs 1st, runs to fixed-point, and runs 8 >>> times in the -O2 pipeline. Reassociate runs 1 time and doesn't run...

On Thu, May 10, 2018 at 12:05 PM, Hiroshi Yamauchi <yamauchi at google.com> wrote: > > > On Wed, May 9, 2018 at 8:24 PM Daniel Berlin <dberlin at dberlin.org> wrote: > >> >> >> On Wed, May 9, 2018 at 10:39 AM, Hiroshi Yamauchi <yamauchi at google.com> >> wrote: >> >>> >>> >>> On Tue, May 8, 2018 at 11:15 AM

On Wed, May 9, 2018 at 10:39 AM, Hiroshi Yamauchi <yamauchi at google.com> wrote: > > > On Tue, May 8, 2018 at 11:15 AM Daniel Berlin <dberlin at dberlin.org> wrote: > >> >> >> On Tue, May 8, 2018 at 10:38 AM, Hiroshi Yamauchi via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> ( >>> ​I came across this issue in

On Wed, May 9, 2018 at 8:24 PM Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Wed, May 9, 2018 at 10:39 AM, Hiroshi Yamauchi <yamauchi at google.com> > wrote: > >> >> >> On Tue, May 8, 2018 at 11:15 AM Daniel Berlin <dberlin at dberlin.org> >> wrote: >> >>> >>> >>> On Tue, May 8, 2018 at 10:38 AM,

On Thu, May 10, 2018 at 12:49 PM Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Thu, May 10, 2018 at 12:05 PM, Hiroshi Yamauchi <yamauchi at google.com> > wrote: > >> >> >> On Wed, May 9, 2018 at 8:24 PM Daniel Berlin <dberlin at dberlin.org> wrote: >> >>> >>> >>> On Wed, May 9, 2018 at 10:39 AM, Hiroshi

> 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

On Fri, May 11, 2018 at 2:37 PM, Hiroshi Yamauchi <yamauchi at google.com> wrote: > > > On Thu, May 10, 2018 at 12:49 PM Daniel Berlin <dberlin at dberlin.org> > wrote: > >> >> >> On Thu, May 10, 2018 at 12:05 PM, Hiroshi Yamauchi <yamauchi at google.com> >> wrote: >> >>> >>> >>> On Wed, May 9, 2018 at 8:24

On Fri, May 11, 2018 at 7:20 PM Hal Finkel <hfinkel at anl.gov> wrote: > > On 05/11/2018 08:40 PM, Daniel Berlin via llvm-dev wrote: > > > > On Fri, May 11, 2018 at 2:37 PM, Hiroshi Yamauchi <yamauchi at google.com> > wrote: > >> >> >> On Thu, May 10, 2018 at 12:49 PM Daniel Berlin <dberlin at dberlin.org> >> wrote: >>

On 05/11/2018 08:40 PM, Daniel Berlin via llvm-dev wrote: > > > On Fri, May 11, 2018 at 2:37 PM, Hiroshi Yamauchi <yamauchi at google.com > <mailto:yamauchi at google.com>> wrote: > > > > On Thu, May 10, 2018 at 12:49 PM Daniel Berlin > <dberlin at dberlin.org <mailto:dberlin at dberlin.org>> wrote: > > > > On Thu, May

I mentioned this earlier in the thread - I would like to see something like D41574 in the optimizer. It's optimizing code that no other pass does currently, and I don't see any other near-term proposal that gets us those optimizations. Omer, can you rebase that to trunk? I 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

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