[Bug optimization/14341] Missed comparision optimization (jump threading related)

["law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

------- 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 <bb 2> (<L1>); 
 >  # SUCC: 2 (fallthru) 
 > 
 >  # BLOCK 1 
 >  # PRED: 2 (true) 
 ><L0>:; 
 >  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 <i_2(0), i_4(1)>; 
 ><L1>:; 
 >  if (i_1 <= 99999999) goto <L0>; else goto <L2>; 
 >  # SUCC: 3 (false) 1 (true) 
 > 
 >  # BLOCK 3 
 >  # PRED: 2 (false) 
 ><L2>:; 
 >  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