From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20545 invoked by alias); 8 Sep 2005 19:04:33 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 20478 invoked by alias); 8 Sep 2005 19:04:25 -0000 Date: Thu, 08 Sep 2005 19:04:00 -0000 Message-ID: <20050908190425.20477.qmail@sourceware.org> From: "law at redhat dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040610171754.15911.dann@godzilla.ics.uci.edu> References: <20040610171754.15911.dann@godzilla.ics.uci.edu> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug tree-optimization/15911] VRP/DOM does not like TRUTH_AND_EXPR X-Bugzilla-Reason: CC X-SW-Source: 2005-09/txt/msg00990.txt.bz2 List-Id: ------- 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 ; else goto ; > > At label L0, we know that: > > D.1615_10 = 1; > D.1613_11 = 1; > D.1614_12 = 1; > y_13 = ASSERT_EXPR ; > x_14 = ASSERT_EXPR 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