------- Additional Comments From law at redhat dot com 2004-12-13 16:33 -------
Subject: Re: [3.4/4.0 Regression] missing
jump threading because of type changes
On Sun, 2004-12-12 at 17:42 +0000, kazu at cs dot umass dot edu wrote:
> ------- Additional Comments From kazu at cs dot umass dot edu 2004-12-12
> 17:42 -------
> Another (possibly expensive) approach would be to "ignore" statements whose
> results are used only in the basic block we are threading through.
>
> Consider:
>
> # iftmp.0_1 = PHI <1(2), 0(3), 0(1)>;
> <L4>:;
> D.1171_13 = (unsigned char) iftmp.0_1;
> D.1160_14 = (int) D.1171_13;
> D.1145_16 = (unsigned char) D.1160_14;
> if (D.1145_16 != 0) goto <L8>; else goto <L14>;
>
> Note that the LHS of all MODIFY_EXPRs are used only in this basic block.
> So if we get to COND_EXPR and find out that COND_EXPR_COND is a constant
> (due to temporary propagation), then we can safely duplicate this basic block
> and thread an incoming edge (without causing code bloat).
> All the duplicate copies of MODIFY_EXPRs will be removed as dead code.
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.
jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18576
