similar to: [LLVMdev] Reassociate fix for 3.2

The reassociate patch is also ok with me. -Chris On Nov 21, 2012, at 2:26 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Pawel, > >> I would like to merge r168035, r168181 and r168291 as >> one reassociate changeset: > > r168181 has nothing to do with reassociate, so should be separate. r168035 and > r168291 have no logical connection so I don't think

Hi Pawel, > I would like to merge r168035, r168181 and r168291 as > one reassociate changeset: r168181 has nothing to do with reassociate, so should be separate. r168035 and r168291 have no logical connection so I don't think they should be merged as one changeset. > Have you heard from Chris regarding r168291? >

Fwiw, I approve both of these patches if they are still unmerged. -Chris On Nov 18, 2012, at 11:41 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Pawel, > >>> Can you provide some examples of the problems you are seeing? >> >> Here is what happens. >> >> I get a message "could you please include/add/merge this r16xxxx into >>

Duncan, I would like to merge r168035, r168181 and r168291 as one reassociate changeset: Have you heard from Chris regarding r168291? http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/156364.html Pawel > On 20/11/12 05:57, Chris Lattner wrote: >> Fwiw, I approve both of these patches if they are still unmerged. > ... >>>

Hi Pawel, >> Can you provide some examples of the problems you are seeing? > > Here is what happens. > > I get a message "could you please include/add/merge this r16xxxx into > 3.2?". And my immediate reaction is sure, no problem this fixes > PR/issue/crash so it is important. But are you the code owner > and do you approve? So I have to go and start checking

On 20/11/12 05:57, Chris Lattner wrote: > Fwiw, I approve both of these patches if they are still unmerged. ... >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/155994.html >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/156206.html Thanks Chris. Can you please also give your go ahead for this nasty reassociate infinite loop

> On Sat, Nov 17, 2012 at 7:40 PM, Pawel Wodnicki <pawel at 32bitmicro.com>wrote: > >> On 11/17/2012 6:35 PM, Chris Lattner wrote: >>> >>> On Nov 17, 2012, at 9:57 AM, Nadav Rotem <nrotem at apple.com> wrote: >>> >>>> I think that the code owner process is becoming complicated and I am >> not sure if it serves Chris's

Hi Pawel, can you please pull this into the 3.2 branch: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/156206.html It fixes a wrong simplification of "A+B==B+A". Thanks, Duncan.

On Sun, Nov 18, 2012 at 11:41 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Pawel, > > >>> Can you provide some examples of the problems you are seeing? >> >> >> Here is what happens. >> >> I get a message "could you please include/add/merge this r16xxxx into >> 3.2?". And my immediate reaction is sure, no problem this

On Thu, Apr 25, 2013 at 9:18 AM, Arnold Schwaighofer < aschwaighofer at apple.com> wrote: > > 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

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

Akira, > Pawel, > > Is it still not too late to merge these patches? > > r168471 > r168460 > r168458 > r168456 > r168455 > r168453 > r168450 > r168448 > > These patches fix a bug in mips backend's GOT implementation and add > support for big-GOT relocations. That's quite a list of patches! To get them into the 3.2 release you would first

Hi Pawel, I guess the code owner could be noted in each source file. Eg: in SelectionDAGBuilder.cpp, there could be a line in the comment block at the start: // Code owner: Owen Anderson (resistor at mac.com) Then anyone working on a bug or with questions about code instantly knows who to turn to. Ciao, Duncan.

Pawel, Is it still not too late to merge these patches? r168471 r168460 r168458 r168456 r168455 r168453 r168450 r168448 These patches fix a bug in mips backend's GOT implementation and add support for big-GOT relocations. Thank you. On Tue, Nov 27, 2012 at 7:35 PM, Pawel Wodnicki <root at 32bitmicro.com> wrote: > Hello, > > Just a quick reminder that the November 29th

I think that the code owner process is becoming complicated and I am not sure if it serves Chris's original intent. I don't think that we need to change every file nor do we need an automatic tool to find the owner. I think that a simple text file, or a section in the docs is enough. On Nov 17, 2012, at 2:51, Duncan Sands <baldrick at free.fr> wrote: > Hi Pawel, I guess the code

Hi Pawel, can you please pull this dragonegg patch into 3.2. I am the code owner for dragonegg. Thanks a lot, Duncan. On 28/11/12 13:44, Duncan Sands wrote: > Author: baldrick > Date: Wed Nov 28 06:44:50 2012 > New Revision: 168787 > > URL: http://llvm.org/viewvc/llvm-project?rev=168787&view=rev > Log: > Add support for GCC's vector copysign builtins, fixing

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

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 =

On 1/11/2013 3:59 PM, Brooks Davis wrote: > On Fri, Jan 11, 2013 at 02:47:01PM -0600, Pawel Wodnicki wrote: >> On 1/11/2013 2:40 PM, Brooks Davis wrote: >>> On Fri, Jan 11, 2013 at 09:33:17PM +0100, Benjamin Kramer >>> wrote: >>>> >>>> On 11.01.2013, at 21:31, Justin Holewinski >>>> <justin.holewinski at gmail.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 should contribute a value”); My understanding is that these assertions enforce that when processing an