------- 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
