From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6813 invoked by alias); 1 Mar 2004 04:28:22 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 6795 invoked by alias); 1 Mar 2004 04:28:21 -0000 Date: Mon, 01 Mar 2004 04:28:00 -0000 Message-ID: <20040301042821.6793.qmail@sources.redhat.com> From: "law at redhat dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040229062941.14341.pinskia@gcc.gnu.org> References: <20040229062941.14341.pinskia@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug optimization/14341] Missed comparision optimization (jump threading related) X-Bugzilla-Reason: CC X-SW-Source: 2004-03/txt/msg00038.txt.bz2 List-Id: ------- Additional Comments From law at redhat dot com 2004-03-01 04:28 ------- Subject: Re: Missed comparision optimization (jump threading related) In message <20040229142002.10721.qmail@sources.redhat.com>, "steven at gcc dot gnu dot org" writes: > >------- Additional Comments From steven at gcc dot gnu dot org 2004-02-29 14 >:19 ------- >Tree dump after DCE1: > >t () >{ > int x; > int i; > int T.0; > > # BLOCK 0 > # PRED: ENTRY (fallthru) > i_2 = 0; > goto (); > # SUCC: 2 (fallthru) > > # BLOCK 1 > # PRED: 2 (true) >:; > T.0_3 = i_1 <= 99999999; > f (T.0_3); > i_4 = i_1 + 1; > # SUCC: 2 (fallthru) > > # BLOCK 2 > # PRED: 1 (fallthru) 0 (fallthru) > # i_1 = PHI ; >:; > if (i_1 <= 99999999) goto ; else goto ; > # SUCC: 3 (false) 1 (true) > > # BLOCK 3 > # PRED: 2 (false) >:; > return; > # SUCC: EXIT > >} > >The dominator tree looks like this: > >bb0 >| >bb2 (contains loop exit condition "i < 100000000") >|\ >| \ >| \ >| bb1 (contains "f(i < 100000000);") >| >bb3 > >So the loop exit condition dominates the function call and we should be able >to optimize that test. But what the tree dumps don't show is that the types of those expressions are fundamentally different. So while it may appear that the expressions are the same, they are, from the compiler's standpoint different. In the stagement "T.0_3 = i_1 <= 99999999" The expression i_1 <= 99999999 has a signed integer type as mandated by the C standard. In the statement "if (i1 <= 99999999) ..." the expression i1 <= 99999999 has a boolean type. Those types differ in significant ways. They differ in signedness, their underlying modes and width of the datatype. The compiler has to be extremely careful when creating equivalences for objects which have types which differ in these ways. In this specific case, both types are integers and the range of the expression they generate is 0..1 inclusive, so there may be something we can do. Then again, this may prove too intrusive and ugly to try and fix. In general, the first thing to do anytime you see a seemingly redundant expression that is not eliminated is to verify that the underlying types of the expressions are equivalent. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14341