From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12847 invoked by alias); 26 Oct 2015 10:30:42 -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 12835 invoked by uid 89); 26 Oct 2015 10:30:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (146.101.78.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 26 Oct 2015 10:30:40 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-13-0T3w3xjNSe-ViJ9mchS7hw-1; Mon, 26 Oct 2015 10:30:35 +0000 Received: from localhost ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2015 10:30:35 +0000 From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener ,GCC Patches , richard.sandiford@arm.com Cc: GCC Patches Subject: Re: Allow more complex call replacements in gimple-fold.c References: <87si4yvuey.fsf@e105548-lin.cambridge.arm.com> Date: Mon, 26 Oct 2015 10:32:00 -0000 In-Reply-To: (Richard Biener's message of "Mon, 26 Oct 2015 11:11:16 +0100") Message-ID: <87d1w1vs50.fsf@e105548-lin.cambridge.arm.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 X-MC-Unique: 0T3w3xjNSe-ViJ9mchS7hw-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2015-10/txt/msg02681.txt.bz2 Richard Biener writes: > On Mon, Oct 26, 2015 at 10:41 AM, Richard Sandiford > wrote: >> An upcoming patch adds a match.pd rule that folds pow(pow(x,y),z) >> to pow(x,y*z). This fold can reuse the existing pow gimple statement >> and simply replace the operands with x and y*z. However, the y*z >> itself requires a separate gimple statement and the code wasn't >> prepared to handle that. >> >> Tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-linux-gnueabi. >> OK to install? > > Hmm, I put the assert there because of the !inplace case but I see the > is_tree_code case alredy behaves the same. > > I think the intent of fold_stmt_inplace (and thus the 'inplace' case) > was that no additional stmts are inserted (and obviously the > stmt itself being not replaced, so gsi_stmt () is the same before and > after). > > So I think both the is_gimple_assign && is_tree_code and the > case you are amending need a > > if (inplace && !gimple_seq_empty_p (*seq)) > return false; OK. I was wondering about that, but the comment isn't clear whether inserting extra statements before the original statement is OK, as long as the final statement has the same form. If this hasn't caused problems for tree codes, do you think that means that callers don't care about extra statements matter in practice, that there simply aren't many fold patterns like this, or that most cases where this kind of fold hits are caught earlier? Just worried about introducing a pessimisation... Should we simply have that check before: if (gcond *cond_stmt =3D dyn_cast (stmt)) so that it's common to all cases? Thanks, Richard