https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80198
Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> --- How would building equivalences help? Looking at the gcc.dg/tree-ssa/20030922-2.c testcase, the reason it works with Jeff's patch is that we are lucky enough on that exact testcase starting with: if (_6 != _11) goto <bb 3>; [69.50%] else goto <bb 6>; [30.50%] <bb 3> [69.50%]: target_bb.3_12 = target_bb; if (_11 == target_bb.3_12) goto <bb 4>; [37.68%] else goto <bb 6>; [62.32%] <bb 4> [26.19%]: if (_6 != target_bb.3_12) and first replace the target_bb.3_12 due to the extra added SSA_NAME_VALUE to _11 in the last GIMPLE_COND above during cprop_operand and then eliminate_redundant_computations do avail_exprs_stack->lookup_avail_expr (stmt, insert, true); on that if (_6 != _11) and find it. If we are unlucky enough and say have if (_6 != _11) in the bb4 and replace that with if (_6 != target_bb.3_12), then we won't find it. Consider say -O1 -fno-tree-fre: struct rtx_def; typedef struct rtx_def *rtx; struct rtx_def { int bb; }; int *block_to_bb; int target_bb; int rgn_rank (rtx insn1, rtx insn2) { int a = block_to_bb[insn1->bb]; int b = block_to_bb[insn2->bb]; if (a != b) if (b == target_bb && a != b) return 1; } Here dom2 with the r233207 change reverted is optimized into just two GIMPLE_CONDs, while current trunk does not (manages to do it only during dom3). As the first if (_6 != _11) is entered before we have any equivalences recorded (and the equivalences are only temporary anyway, might not be in effect in all the places where the if (_6 != _11) is in effect), I think there is no hope for some canonicalization of the stmt we want to look up at the place we have some equivalences for it temporarily recorded can help in doing just a single hash table lookup. Perhaps we should revert r233207 and in addition to the SSA_NAME_VALUE record the temporary equivalences some way in another data structure (e.g. forward and backward chains to other SSA_NAME versions, chains could be just unsigned int SSA_NAME_VERSIONs or whatever). Then e.g. avail_exprs_stack::lookup_avail_expr if it detects one or both arguments of the stmt have temporary equivalences recorded could just loop through all the equivalence combinations (perhaps with some upper bound), trying to (!insert) find the available expression. And if everything else fails do the insert lookup (if requested) on the SSA_NAMEs as in the stmt last. Thoughts on this?