This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] tree-ssa-dom.c: Use VEC(vrp_element_p,heap) instead ofVARRAY.
- From: Jeffrey A Law <law at redhat dot com>
- To: Kazu Hirata <kazu at cs dot umass dot edu>
- Cc: dnovillo at redhat dot com, gcc-patches at gcc dot gnu dot org, nathan at codesourcery dot com
- Date: Mon, 02 May 2005 10:49:22 -0600
- Subject: Re: [patch] tree-ssa-dom.c: Use VEC(vrp_element_p,heap) instead ofVARRAY.
- References: <1114609621.370.1.camel@localhost.localdomain> <20050427.121951.85389895.kazu@cs.umass.edu> <20050427170157.GA27784@topo.toronto.redhat.com> <20050427.131228.122061440.kazu@cs.umass.edu>
- Reply-to: law at redhat dot com
On Wed, 2005-04-27 at 13:12 -0400, Kazu Hirata wrote:
> Hi Diego,
>
> > > Well, we can probably feed DOM similar information using
> > > SSA_NAME_VALUE_RANGE.
> > >
> > If DOM doesn't use the VRP info for jump threading, then you
> > should be able to remove it. Do make sure that tree-vrp.c is not
> > being silly on things caught by DOM, though.
>
> In fact, most of my VRP patches (and some missed optmization in
> FRE/PRE) were inspired by instrumenting DOM and threadupdate to print
> out a message whenever all outgoing edges of a basic block are
> "threaded" to the same destination, which is just another way of
> saying "folding COND_EXPR_COND into a constant". :-)
Yea, that's a pretty good idea -- except for a small number of extreme
cases, if the threader threads all incoming edges to the same
outgoing edge, then there's a good chance we can/should be looking
to catch that case in another optimizer such as VRP.
jeff