From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19163 invoked by alias); 24 Jun 2005 22:06:45 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 19137 invoked by uid 22791); 24 Jun 2005 22:06:42 -0000 Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 24 Jun 2005 22:06:42 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id j5OM6eSl009629 for ; Fri, 24 Jun 2005 15:06:40 -0700 (PDT) Received: from relay2.apple.com (relay2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Fri, 24 Jun 2005 15:06:40 -0700 Received: from [17.201.21.188] (jahan5.apple.com [17.201.21.188]) by relay2.apple.com (8.12.11/8.12.11) with ESMTP id j5OM6cv2009445 for ; Fri, 24 Jun 2005 15:06:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v728) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: gcc@gcc.gnu.org From: Fariborz Jahanian Subject: [RFH] - Less than optimal code compiling 252.eon -O2 for x86 Date: Fri, 24 Jun 2005 22:06:00 -0000 X-SW-Source: 2005-06/txt/msg01025.txt.bz2 A source file mrSurfaceList.cc of 252.eon produces less efficient code initializing instance objects to 0 at -O2 than at -O1. Behavior is random and it does not happen on all x86 platforms and making the test smaller makes the problem go away. But here is what I found out is the cause. When source is compiled with -O1 -march=pentium4, 'cse' phase sees the following pattern initializing a 'double' with 0. (insn 18 13 19 0 (set (reg:SF 109) (mem/u/i:SF (symbol_ref/u:SI ("*LC11") [flags 0x2]) [0 S4 A32])) -1 (nil) (nil)) (insn 19 18 20 0 (set (mem/s/j:DF (plus:SI (reg/f:SI 20 frame) (const_int -32 [0xffffffffffffffe0])) [0 objectBox.pmin.e+16 S8 A128]) (float_extend:DF (reg:SF 109))) 86 {*extendsfdf2_sse} (nil) (nil)) Then fold_rtx routine converts it into its reduced form, resulting in optimum code: (insn 19 13 21 0 (set (mem/s/j:DF (plus:SI (reg/f:SI 20 frame) (const_int -32 [0xffffffffffffffe0])) [0 objectBox.pmin.e+16 S8 A128]) (const_double:DF 0.0 [0x0.0p+0])) 64 {*movdf_nointeger} (nil) (nil)) But when the same source is compiled with -O2 march=pentium4, 'cse' phase sees a slightly different pattern (note that float_extend:DF has moved) (insn 18 13 19 0 (set (reg:DF 109) (float_extend:DF (mem/u/i:SF (symbol_ref/u:SI ("*LC13") [flags 0x2]) [0 S4 A32]))) -1 (nil) (nil)) (insn 19 18 20 0 (set (mem/s/j:DF (plus:SI (reg/f:SI 20 frame) (const_int -32 [0xffffffffffffffe0])) [0 objectBox.pmin.e+16 S8 A128]) (reg:DF 109)) 64 {*movdf_nointeger} (nil) (nil)) This cannot be simplified by fold_rtx, resulting in less efficient code. Change in pattern is most likely because of additional tree optimization phases running at -O2. If so, then should the cse be taught to simplify the new rtl pattern. Or, the tree optimizer phase responsible for the less than optimal tree need be twiked to generate the same tree as with -O1? Thanks, fariborz