similar to: [PATCH/RFC] Modifying reassociate for improved CSE: fairly large perf gains

Any idea why clusters five and six fall off the scale in the following? library(cluster) library(maptree) data(flower) dfl2<-daisy(flower,type=list(asymm=c(1,3),ordratio=7)) hdfl2<-hclust(dfl2) prune.dfl2<-prune.clust(hdfl2,k=6) plot(prune.dfl2) Of course the following will display all six clusters, but without a scale: draw.tree(prune.dfl2) Best wishes, Mikkel Mikkel Grum

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

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

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

> Hi Chad, > > Thanks for you answer. > >> On Feb 4, 2015, at 11:22 AM, Chad Rosier <mcrosier at codeaurora.org> >> wrote: >> >>>> 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

Hi Andrew, Shuxin, Thanks for the explanation about 'Reassociate'. The problem is indeed that one of the variables, becomes loop invariant after some of the loop transformations. > -----Original Message----- > From: Andrew Trick [mailto:atrick at apple.com] [...] > Right. Reassociate ranks expressions by their order in the IR, so shouldn't > make matters worse, but it

On Tue, May 5, 2015 at 10:31 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > 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

On Apr 23, 2013, at 10:37 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > As far as I can understand of the code, the Reassociate tries to achieve this result by its "ranking" mechanism. > > If it dose not, it is not hard to achieve this result, just restructure the expression in a way such that > the earlier definition of the sub-expression is permute earlier in

I'm resending this bug report with a new example. As seen below, cut.dendrogram gives an error message for some heights, but not for others and with some datasets adn not others. I can't see why. Last time I unwittingly sent my message with HTML formatting. This time I'm travelling and using an e-mail system that I am unfamiliar with. As far as I can see, I am not using HTML.

Owen/All, I've been working on adding support for reassociation with unsafe math (see: http://reviews.llvm.org/D4129). Do you know if this change, r156323, is still necessary? Specifically, do we need the reassociation pass to canonicalize FP operands for CSE to work effectively? This kinda scares me if it does! :( Side note: Without this canonicalization, I did see a 3% regression in Mesa

As far as I can understand of the code, the Reassociate tries to achieve this result by its "ranking" mechanism. If it dose not, it is not hard to achieve this result, just restructure the expression in a way such that the earlier definition of the sub-expression is permute earlier in the resulting expr. e.g. outer-loop1 x= outer-loop2 y =

It's an interesting problem. The best stuff I've seen published is by Cooper, Eckhart, & Kennedy, in PACT '08. Cooper gives a nice intro in one of his lectures: http://www.cs.rice.edu/~keith/512/2012/Lectures/26ReassocII-1up.pdf I can't tell, quickly, what's going on in Reassociate; as usual, the documentation resolutely avoids giving any credit for the ideas. Why is that?

Hi, I am investigating a performance degradation between llvm-3.1 and llvm-3.2 (Note: current top-of-tree shows a similar degradation) One issue I see is the following: - 'loop invariant code motion' seems to be depending on the result of the 'reassociate expression' pass: In the samples below I observer the following behavior: Both start with the same expression: %add = add

On Apr 25, 2013, at 10:51 AM, Preston Briggs <preston.briggs at gmail.com> wrote: > It's an interesting problem. > The best stuff I've seen published is by Cooper, Eckhart, & Kennedy, in PACT '08. > Cooper gives a nice intro in one of his lectures: http://www.cs.rice.edu/~keith/512/2012/Lectures/26ReassocII-1up.pdf > I can't tell, quickly, what's going on

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

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

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