From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24934 invoked by alias); 26 Sep 2011 11:01:01 -0000 Received: (qmail 24926 invoked by uid 22791); 26 Sep 2011 11:01:00 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_OV X-Spam-Check-By: sourceware.org Received: from mail-yx0-f175.google.com (HELO mail-yx0-f175.google.com) (209.85.213.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 26 Sep 2011 11:00:45 +0000 Received: by yxj17 with SMTP id 17so4615994yxj.20 for ; Mon, 26 Sep 2011 04:00:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.203.17 with SMTP id a17mr6163494ybg.409.1317034845102; Mon, 26 Sep 2011 04:00:45 -0700 (PDT) Received: by 10.150.177.4 with HTTP; Mon, 26 Sep 2011 04:00:45 -0700 (PDT) In-Reply-To: <4e802c3d.94ebd80a.4b1f.ffff8101SMTPIN_ADDED@mx.google.com> 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> Date: Mon, 26 Sep 2011 14:33:00 -0000 Message-ID: Subject: Re: A case that PRE optimization hurts performance From: Richard Guenther To: Jiangning Liu Cc: gcc@gcc.gnu.org, Jeff Law Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00319.txt.bz2 On Mon, Sep 26, 2011 at 9:39 AM, Jiangning Liu wrot= e: >> > * Without PRE, >> > >> > Path1: >> > =A0 =A0 =A0 =A0movl =A0 =A0$2, %eax >> > =A0 =A0 =A0 =A0cmpl =A0 =A0$1, %eax >> > =A0 =A0 =A0 =A0je =A0 =A0 =A0.L3 >> > >> > Path2: >> > =A0 =A0 =A0 =A0movb =A0 =A0$3, %al >> > =A0 =A0 =A0 =A0cmpl =A0 =A0$1, %eax >> > =A0 =A0 =A0 =A0je =A0 =A0 =A0.L3 >> > >> > Path3: >> > =A0 =A0 =A0 =A0cmpl =A0 =A0$1, %eax >> > =A0 =A0 =A0 =A0jne =A0 =A0 .L14 >> > >> > * With PRE, >> > >> > Path1: >> > =A0 =A0 =A0 =A0movl =A0 =A0$1, %ebx >> > =A0 =A0 =A0 =A0movl =A0 =A0$2, %eax >> > =A0 =A0 =A0 =A0testb =A0 %bl, %bl >> > =A0 =A0 =A0 =A0je =A0 =A0 =A0.L3 >> > >> > Path2: >> > =A0 =A0 =A0 =A0movl =A0 =A0$1, %ebx >> > =A0 =A0 =A0 =A0movb =A0 =A0$3, %al >> > =A0 =A0 =A0 =A0testb =A0 %bl, %bl >> > =A0 =A0 =A0 =A0je =A0 =A0 =A0.L3 >> > >> > Path3: >> > =A0 =A0 =A0 =A0cmpl =A0 =A0$1, %eax >> > =A0 =A0 =A0 =A0setne =A0 %bl >> > =A0 =A0 =A0 =A0testb =A0 %bl, %bl >> > =A0 =A0 =A0 =A0jne =A0 =A0 .L14 >> > >> > Do you have any more thoughts? >> >> It seems to me that with PRE all the testb %bl, %bl >> should be evaluated at compile-time considering the >> preceeding movl $1, %ebx. =A0Am I missing something? >> > > Yes. Can this be done by PRE or any other optimizations in middle end? Hm, the paths as you quote them are obfuscated by missed jump-threading. On the tree level we have # s_2 =3D PHI <2(5), 3(4), 2(6), s_25(7)> # prephitmp.6_1 =3D PHI <1(5), 1(4), 1(6), prephitmp.6_3(7)> : t_14 =3D t_24 + 1; D.2729_6 =3D MEM[base: t_14, offset: 0B]; D.2732_7 =3D D.2729_6 !=3D 0; D.2734_9 =3D prephitmp.6_1 & D.2732_7; if (D.2734_9 !=3D 0) where we could thread the cases with prephitmp.6_1 =3D=3D 1, ultimately removing the & and forwarding the D.2729_6 !=3D 0 test. Which would of course cause some code duplication. Jeff, you recently looked at tree jump-threading, can you see if we can improve things on this particular testcase? Thanks, Richard. > Thanks, > -Jiangning > >> Richard. >> > > > > >