http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52631
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-03-21 00:14:37 UTC --- (In reply to comment #3) > Hmm, but then you'd pessimize the case where b_2 & 1 were available? Thus, > don't you need to do the lookup with the original expression anyway if the > lookup for the simplified expression fails? Oh, and doesn't the testcase > show a missed canonicalization? My patch just gets us back to where we were before tuples. Before tuples we would do: else if (simplified) { if (TREE_CODE (lhs) == SSA_NAME) { VN_INFO (lhs)->has_constants = expr_has_constants (simplified); /* We have to unshare the expression or else valuizing may change the IL stream. */ VN_INFO (lhs)->expr = unshare_expr (simplified); } rhs = simplified; } And then use rhs in the switch statement for visit_unary_op/visit_binary_op . I don't see a missed canonicalization anywhere as we are combing (a>>31)&1 and then calling fold on it and it returns a>>31 which is the correct thing to do. The main issue is we never do a lookup on a>>31 after we do the simplification, we only do it on the b&1. Let me see if I can understand the question about b&1 being available, a testcase would be something like: unsigned f(unsigned a, unsigned b, unsigned c) { unsigned d = c&1; if(b) c = a>>31; return (c & 1) + d; } --- CUT --- PRE produces (with both the patch and before): <bb 2>: d_3 = c_2(D) & 1; if (b_4(D) != 0) goto <bb 3>; else goto <bb 5>; <bb 5>: goto <bb 4>; <bb 3>: c_6 = a_5(D) >> 31; pretmp.3_11 = c_6 & 1; <bb 4>: # c_1 = PHI <c_2(D)(5), c_6(3)> # prephitmp.4_12 = PHI <d_3(5), pretmp.3_11(3)> D.1713_7 = prephitmp.4_12; D.1712_8 = D.1713_7 + d_3; return D.1712_8; Which means we don't even do the simplifications while doing a PRE anyways.