[Bug tree-optimization/18576] [3.4/4.0 Regression] missing jump threading because of type changes

["kazu at cs dot umass dot edu" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From kazu at cs dot umass dot edu  2004-12-13 17:13 -------
Subject: Re:  [3.4/4.0 Regression] missing
 jump threading because of type changes

Hi Jeff,

> No.  The way to handle this is to remove all the nonsense about proving
> that statements in the block are NOPs.  That precondition for threading
> is no longer necessary and just gets in the way of doing a good job
> at optimizing.
> 
> This is a great example of the kind of code I expect the threader to
> be able to handle once that lameness is removed.

Sorry, the example was a little bad.  I had something like this in my
mind.

  # iftmp.0_1 = PHI <a_1(2), 0(3)>;
<L4>:;
  D.1171_13 = iftmp.0_1 + 1;
  if (D.1171_13 != 0) goto <L8>; else goto <L14>;

Note that D.1171_13 is partially constant.  I guess we should really
transform this into

<bb 2>:
  a_2 = a_1 + 1;

  # D.1171_13 = PHI <a_2(2), 1(3)>;
<L4>:;
  if (D.1171_13 != 0) goto <L8>; else goto <L14>;

Of course, if there are a lot of incoming edges that do not have
constant PHI arguments, sending "+ 1" upstream would cause code bloat.
We could "fix" this by creating a helper block that does "+ 1" and
then jump to L4, but things get more and more complicated, and I don't
know if it's profitable.

Another thing I've seen blocking a jump threading opportunity is:

<L4>:;
  D.1171_13 = global_variable;
  if (D.1171_13 != 0) goto <L8>; else goto <L14>;

Where the value of global_variable is known on one of the incoming
edges of L4.  I guess we need to remove partially redundancy
associated with this load and shouldn't blame the jump threader.  That
is, we should transform the code above to

  D.1171_13 = PHI <...(2), ...(3)>
<L4>:;
  if (D.1171_13 != 0) goto <L8>; else goto <L14>;

Kazu Hirata


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18576