From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14983 invoked by alias); 22 Feb 2006 21:45:36 -0000 Received: (qmail 14894 invoked by alias); 22 Feb 2006 21:45:32 -0000 Date: Wed, 22 Feb 2006 21:45:00 -0000 Message-ID: <20060222214532.14893.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/26406] Fowardprop does harm for VRP to figure out if a point is non zero In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "law at redhat dot com" 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 X-SW-Source: 2006-02/txt/msg02588.txt.bz2 List-Id: ------- Comment #12 from law at redhat dot com 2006-02-22 21:45 ------- Subject: Re: Fowardprop does harm for VRP to figure out if a point is non zero On Wed, 2006-02-22 at 20:55 +0000, rguenth at gcc dot gnu dot org wrote: > > ------- Comment #11 from rguenth at gcc dot gnu dot org 2006-02-22 20:55 ------- > So I suppose VRP cannot see "backwards" for > > i_2 = j_1; > if (i_2 == 0) > return j_1; > > ? (of course copyprop would clean this up, but suppose for a moment this > gets to VRP) Nope, it can't. It's not just the lack of backwards propagation, but also the fact that i is unused in the subgraphs after the conditional, so VRP won't record any information for either i or j in this kind of example. Fixing VRP to gather data for "i" in this example would result in a pretty significant compile-time hit. I'll note this was one of the reasons why we moved copyprop to run immediately before VRP -- copies in the IL were hiding a nontrivial number of detectable and useful ranges. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26406