From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19604 invoked by alias); 2 Dec 2011 11:51:12 -0000 Received: (qmail 19594 invoked by uid 22791); 2 Dec 2011 11:51:11 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_TM,TW_XV,TW_XZ X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 02 Dec 2011 11:50:58 +0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/50904] [4.7 regression] pessimization when -fno-protect-parens is enabled by -Ofast Date: Fri, 02 Dec 2011 11:51:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: ebotcazou at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-12/txt/msg00153.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904 --- Comment #22 from Richard Guenther 2011-12-02 11:50:39 UTC --- One thing I notice (and that's the only difference I can spot at the tree level) is that we do not CSE the **2s of a = sqrt((rect_inductor%v2%x - rect_inductor%v4%x)**2 + (rect_inductor%v2%y - & rect_inductor%v4%y)**2 + (rect_inductor%v2%z - rect_inductor%v4%z)**2) and xxvec = rect_inductor%v2%x - rect_inductor%v4%x xyvec = rect_inductor%v2%y - rect_inductor%v4%y xzvec = rect_inductor%v2%z - rect_inductor%v4%z magnitude = sqrt(xxvec**2 + xyvec**2 + xzvec**2) because while the former has PAREN_EXPRs the latter does not and we do not consider : D.2113_79 = rect_inductor_78(D)->v2.x; D.2114_80 = rect_inductor_78(D)->v4.x; D.2115_81 = D.2113_79 - D.2114_80; D.1959_82 = ((D.2115_81)); D.1960_83 = __builtin_pow (D.1959_82, 2.0e+0); ... D.1978_168 = __builtin_pow (D.2115_81, 2.0e+0); D.1960_83 and D.1978_168 as equivalent (they are, value-wise, but we cannot easily replace one with the other using our current value-numbering machinery). We could clevery see that ((x))**2 is equal to ((x**2)) but that would not help for seeing the CSE opportunity of the following sum and sqrt either. I wonder if Fortran, with -fprotect-parens, really has different semantics for tem = 2 * a; c = b / tem; vs. c = b / (2 * a); ? Thus, is not every statement supposed to be wrapped in parens with -fprotect-parens? So that tem = 2 * a; becomes tem = ( 2 * a ); implicitely? I see that placing ()s at the toplevel of the relevant stmts in the source has the desired effect of enabling CSE and the tree level optimization differences vanish. Thus, this is a question of 1) correctness of the -fprotect-parens implementation in the frontend, 2) a question on what optimizations we want to perform on protected expressions. Relevant transform is CSE sqrt (x*x + y*y + z*z) and sqrt (((x))*((x)) + ((y))*((y)) + ((z))*((z)))