This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/15911] VRP/DOM does not like TRUTH_AND_EXPR
- From: "law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 8 Sep 2005 19:04:25 -0000
- Subject: [Bug tree-optimization/15911] VRP/DOM does not like TRUTH_AND_EXPR
- References: <20040610171754.15911.dann@godzilla.ics.uci.edu>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From law at redhat dot com 2005-09-08 19:04 -------
Subject: Re: VRP/DOM does not like
TRUTH_AND_EXPR
On Thu, 2005-09-08 at 18:20 +0000, dnovillo at gcc dot gnu dot org
wrote:
> ------- Additional Comments From dnovillo at gcc dot gnu dot org 2005-09-08 18:20 -------
>
> This would be fixable inside VRP. Essentially we would need to insert chains of
> ASSERT_EXPRs to represent various predicates:
>
> D.1613_3 = x_2 > 5555;
> D.1614_5 = y_4 <= 6665;
> D.1615_6 = D.1613_3 && D.1614_5;
> if (D.1615_6) goto <L0>; else goto <L8>;
>
> At label L0, we know that:
>
> D.1615_10 = 1;
> D.1613_11 = 1;
> D.1614_12 = 1;
> y_13 = ASSERT_EXPR <y_4, y_4 <= 6665>;
> x_14 = ASSERT_EXPR <x_2, x_2 > 5555>;
>
> which is a bit sickening. It would be Much Better to avoid creating these
> obtuse predicates in fold(), though.
Well, we have a long standing problem with fold using BRANCH_COST to
determine how best to implement certain conditionals. But even if that
were removed, it's fairly straightforward for a programmer (or better
yet some automated code generator) to create these "obtuse" predicates.
I think we'd be better off teaching VRP how to cope with this.
Jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15911