This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Flow crash for conditional branches against a constant
- From: Daniel Jacobowitz <drow at false dot org>
- To: Richard Earnshaw <Richard dot Earnshaw at arm dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 14 Jun 2004 09:13:23 -0400
- Subject: Re: Flow crash for conditional branches against a constant
- References: <20040611154452.GA26000@nevyn.them.org> <1086973215.11466.31.camel@pc960.cambridge.arm.com> <20040611170534.GA30014@nevyn.them.org> <20040612204600.GA4466@nevyn.them.org> <1087206737.29253.14.camel@pc960.cambridge.arm.com>
On Mon, Jun 14, 2004 at 10:52:17AM +0100, Richard Earnshaw wrote:
> No, I don't think so (unless I've misunderstood your patch).
>
> The problem is that we only track the one register in the cond table, by
> removing the constraint that the second argument is against 0, you
> potentially allow
>
> if (a < b)
> op1;
> else if (a >= c)
> op2;
>
> to be transformed into
>
> if (a < b)
> op1;
> else
> op2;
>
> which it might do because it only takes into account 2 of the 3
> constraints required (operand 1 is 'a', comparison is opposite of '<')
> and ignores the third (operand 2 is 'b'). This is clearly not the same.
Could you explain where you think this transformation might happen?
The only things which examine the form of the comparisons in flow.c are
elim_reg_cond, and_reg_cond, not_reg_cond, and ior_reg_cond; they used
to ignore the second operand, but I changed that.
I guess this is the table you're referring to:
/* Indexed by register number, holds a reg_cond_life_info for each
register that is not unconditionally live or dead. */
splay_tree reg_cond_dead;
But that is indexed by the register we're tracking, which is not a, b,
or c; it's something set by op1.
--
Daniel Jacobowitz