This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PR80025] avoid cselib rtx_equal infinite recursion on XOR
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: asolokha at gmx dot com, gcc-patches at gcc dot gnu dot org, bschmidt at redhat dot com, mliska at suse dot cz
- Date: Thu, 23 Mar 2017 15:00:04 +0100
- Subject: Re: [PR80025] avoid cselib rtx_equal infinite recursion on XOR
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jakub at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 2A6087F6C8
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2A6087F6C8
- References: <orwpbiuu6w.fsf@lxoliva.fsfla.org>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Mar 21, 2017 at 07:43:51PM -0300, Alexandre Oliva wrote:
> When two VALUEs are recorded in the cselib equivalence table such that
> they are equivalent to each other XORed with the same expression, if
> we started a cselib equivalence test between say the odd one and the
> even one, we'd end up recursing to compare the even one with the odd
> one, and then again, indefinitely.
>
> This patch cuts off this infinite recursion by recognizing the XOR
> special case (it's the only binary commutative operation in which
> applying one of the operands of an operation to the result of that
> operation brings you back to the other operand) and determining
> whether we have an equivalence without recursing down the infinite
> path.
Is XOR the only special case though? E.g. PLUS or MINUS with
the most negative constant act the same, and I don't see why if unlucky
enough with reverse ops etc. you couldn't get something similar through
combination thereof, perhaps indirectly through multiple VALUEs.
So I think it is safer to just put a cap on the rtx_equal_for_cselib_1
recursion depth (should be enough to bump the depth only when walking
locs of a VALUE). I'll test such a patch.
Jakub