aboutsummaryrefslogtreecommitdiff
path: root/gcc/var-tracking.c
diff options
context:
space:
mode:
authorAlexandre Oliva <aoliva@redhat.com>2015-12-13 20:37:26 +0000
committerAlexandre Oliva <aoliva@gcc.gnu.org>2015-12-13 20:37:26 +0000
commitc779924eee2c26684b32b4a0b15e793884d1cafc (patch)
tree6100f51adbc38b570a0bf6f479816c9e7813abc6 /gcc/var-tracking.c
parent8454aad340922ae794096dd6045990f087b7906f (diff)
downloadgcc-c779924eee2c26684b32b4a0b15e793884d1cafc.zip
gcc-c779924eee2c26684b32b4a0b15e793884d1cafc.tar.gz
gcc-c779924eee2c26684b32b4a0b15e793884d1cafc.tar.bz2
[PR67355] drop dummy zero from reverse VTA ops, fix infinite recursion
VTA's cselib expression hashing compares expressions with the same hash before adding them to the hash table. When there is a collision involving a self-referencing expression, we could get infinite recursion, in spite of the cycle breakers already in place. The problem is currently latent in the trunk, because by chance we don't get a collision. Such value cycles are often introduced by reverse_op; most often, they're indirect, and then value canonicalization takes care of the cycle, but if the reverse operation simplifies to the original value, we used to issue a (plus V (const_int 0)), because at some point adding a plain value V to a location list as a reverse_op equivalence caused other problems. This dummy zero, in turn, caused the value canonicalizer to not fully realize the equivalence, leading to more complex graphs and, occasionally, to infinite recursion when comparing such value-plus-zero expressions recursively. Simply using V solves the infinite recursion from the PR testcase, since the extra equivalence and the preexisting value canonicalization together prevent recursion while the unrecognized equivalence wouldn't, but it exposed another infinite recursion in memrefs_conflict_p: get_addr had a cycle breaker in place, to skip RTL referencing values introduced after the one we're examining, but it wouldn't break the cycle if the value itself appeared in the expression being examined. After removing the dummy zero above, this kind of cycle in the equivalence graph is no longer introduced by VTA itself, but dummy zeros are also present in generated code, such as in the 32-bit x86's pro_epilogue_adjust_stack_si_add epilogue insn generated as part of the builtin longjmp in _Unwind_RaiseException building libgcc's unwind-dw2.o. So, break the recursion cycle for them too. for gcc/ChangeLog PR debug/67355 * var-tracking.c (reverse_op): Don't add dummy zero to reverse ops that simplify back to the original value. * alias.c (refs_newer_value_p): Cut off recursion for expressions containing the original value. From-SVN: r231599
Diffstat (limited to 'gcc/var-tracking.c')
-rw-r--r--gcc/var-tracking.c5
1 files changed, 0 insertions, 5 deletions
diff --git a/gcc/var-tracking.c b/gcc/var-tracking.c
index 9185bfd..07eea84 100644
--- a/gcc/var-tracking.c
+++ b/gcc/var-tracking.c
@@ -5774,11 +5774,6 @@ reverse_op (rtx val, const_rtx expr, rtx_insn *insn)
return;
}
ret = simplify_gen_binary (code, GET_MODE (val), val, arg);
- if (ret == val)
- /* Ensure ret isn't VALUE itself (which can happen e.g. for
- (plus (reg1) (reg2)) when reg2 is known to be 0), as that
- breaks a lot of routines during var-tracking. */
- ret = gen_rtx_fmt_ee (PLUS, GET_MODE (val), val, const0_rtx);
break;
default:
gcc_unreachable ();