From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9594 invoked by alias); 15 Oct 2014 13:04:59 -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 9584 invoked by uid 89); 15 Oct 2014 13:04:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx2.suse.de Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Wed, 15 Oct 2014 13:04:58 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 37AF5AB0C for ; Wed, 15 Oct 2014 13:04:55 +0000 (UTC) Date: Wed, 15 Oct 2014 13:20:00 -0000 From: Richard Biener To: gcc-patches@gcc.gnu.org Subject: [PATCH][0/n] Merge from match-and-simplify Message-ID: User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2014-10/txt/msg01347.txt.bz2 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. Some cases may result from the fact that the autogenerated code from genmatch does not apply selective STRIP_NOPS/STRIP_SIGN_NOPS to the outermost expression operands as fold does. Some cases may result from the fact that the autogenerated code bails out on operands with side-effects (patterns really target GIMPLE where operands never have side-effects). In 10 years (well, maybe earlier) we shouldn't do any expression simplification from the frontends (and thus GENERIC) if not explicitely required by language standards. Thus I expect fold-const.c to "vanish" anyway. Generally it is of course impossible to prove that adding a pattern and removing existing fold-const.c and gimple-fold.c/tree-ssa-forwprop.c code will not regress. But I suppose that's expected and passing the testsuite is fine (together with possibly amending it with testcases for foldings that now should apply on GIMPLE). For stage1 I'd like to merge [1/n] to [5/n] as one revision (well, excluding 3/n) and add patterns in smaller chunks to be able to bisect to issues that show up. Any comments and reviews welcome (I don't think that my maintainership covers enough to simply check this in without approval). Thanks, Richard. -- Richard Biener SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer