From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3613 invoked by alias); 27 Sep 2011 14:56:29 -0000 Received: (qmail 3578 invoked by uid 22791); 27 Sep 2011 14:56:25 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Sep 2011 14:56:11 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8REu9rJ025690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2011 10:56:09 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p8REu8dP014616; Tue, 27 Sep 2011 10:56:09 -0400 Received: from [10.3.113.60] (ovpn-113-60.phx2.redhat.com [10.3.113.60]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p8REu6fE020187; Tue, 27 Sep 2011 10:56:07 -0400 Message-ID: <4E81E406.4090305@redhat.com> Date: Tue, 27 Sep 2011 18:59:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Richard Guenther CC: Jiangning Liu , gcc@gcc.gnu.org Subject: Re: A case that PRE optimization hurts performance References: <4e3762ed.030d440a.1143.2af2SMTPIN_ADDED@mx.google.com> <4e72add8.c9d0e30a.142a.ffffe60eSMTPIN_ADDED@mx.google.com> <4e802c3d.94ebd80a.4b1f.ffff8101SMTPIN_ADDED@mx.google.com> <4E80AB90.6060201@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-09/txt/msg00344.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/27/11 01:30, Richard Guenther wrote: > >> It knows something about prephitmp.6_1 and thus could simplify >> D.2734_9 = prephitmp_6.1 & D.2732_7; to D.2734_9 = D.2732_7; But >> admittedly I have no idea if DOM tries to simplify things other >> than comparisons within the jump threading machinery ... (the >> above block basically ends in if (D.2729_6 != 0 && >> prephitmp_6.1), so I'd guess it's worth to simplify the (complex) >> conditional expression). Jump threading will enter simplified expressions into the hash tables for every statement in the block in an effort to utilize any information available to determine the result of the comparison. However, those simplifications aren't ever reflected back into the IL. The thing to remember is jump threading is tasked detecting cases where the control statement has a predetermined destination utilizing path sensitive information. Expanding it to do general path sensitive optimizations is possible, but at even greater cost. jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOgeQGAAoJEBRtltQi2kC7xX8H/1odgAgNVKdbWk4FtsNPx9xl +xHtQdB2zycD0o0TMdQ+PcllXHaIK+ScIZEcxys1lN9HoEEyhyHPmQi7FZbD807y oTswglsX7hnTM3fMCN62BTFwk6P0QNrbeZ4bsVxF5DkBmMLXbArQ7UEYD9mSHnDv ixi06cUc/x5CXCAbcrAdUQI/9uF9d83myLs3rS3T0g2nPm+chGRN94Bm6ZbrB0hA PjyKiZ4j3z6Yc5bs2GF19Rh7vfjD/9NhKF9t9YwuBky4luLv4RPFsT1JQM3+1yuT tW5xk0et3eUnGFgiLUrF1mkHO/TkSv5iTsDI2tbbCkLCdH3w8Runj21/5qMWXxY= =X10i -----END PGP SIGNATURE-----