From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13468 invoked by alias); 17 Oct 2014 16:36:05 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 13459 invoked by uid 89); 17 Oct 2014 16:36:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ie0-f170.google.com Received: from mail-ie0-f170.google.com (HELO mail-ie0-f170.google.com) (209.85.223.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 17 Oct 2014 16:36:03 +0000 Received: by mail-ie0-f170.google.com with SMTP id rd18so1092838iec.29 for ; Fri, 17 Oct 2014 09:36:00 -0700 (PDT) X-Received: by 10.107.15.224 with SMTP id 93mr2921714iop.86.1413563760637; Fri, 17 Oct 2014 09:36:00 -0700 (PDT) Received: from f1.c.bardezibar.internal (81.37.148.146.bc.googleusercontent.com. [146.148.37.81]) by mx.google.com with ESMTPSA id 93sm819072iol.40.2014.10.17.09.35.59 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 17 Oct 2014 09:35:59 -0700 (PDT) Date: Fri, 17 Oct 2014 16:44:00 -0000 From: Sebastian Pop To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH][0/n] Merge from match-and-simplify Message-ID: <20141017163558.GD29134@f1.c.bardezibar.internal> References: <20141016203852.GB29134@f1.c.bardezibar.internal> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg01765.txt.bz2 Richard Biener wrote: > On Thu, 16 Oct 2014, Sebastian Pop wrote: > > > Richard Biener wrote: > > > > > > I have posted 5 patches as part of a larger series to merge > > > (parts) from the match-and-simplify branch. While I think > > > there was overall consensus that the idea behind the project > > > is sound there are technical questions left for how the > > > thing should look in the end. I've raised them in 3/n > > > which is the only patch of the series that contains any > > > patterns sofar. > > > > > > To re-iterate here (as I expect most people will only look > > > at [0/n] patches ;)), the question is whether we are fine > > > with making fold-const (thus fold_{unary,binary,ternary}) > > > not handle some cases it handles currently. > > > > I have tested on aarch64 all the code in the match-and-simplify against trunk as > > of the last merge at r216315: > > > > 2014-10-16 Richard Biener > > > > Merge from trunk r216235 through r216315. > > > > Overall, I see a lot of perf regressions (about 2/3 of the tests) than > > improvements (1/3 of the tests). I will try to reduce tests. > > Note that the branch goes much further in exercising the machinery > than I want to merge at this point (that applies mostly to all > passes using the SSA propagator such as CCP and VRP and passes > exercising value-numbering - FRE and PRE). I see. Should I run benchmarks only with the patches that you submitted for trunk? > I don't understand AARCH64 assembly very well but the above looks like > RTL issues and/or IVOPTs issues? I should have posted the first diff between the compilers with -fdump-tree-all: that would expose the problem at its root. I have seen that there is a way to dump the folded expressions from the new functionality, is there a flag to print the folded expressions in current trunk? It would be interesting to have the same kind of output, such that we could run a diff between. Thanks, Sebastian